- Use range based for loops
- No need for some !Reg checks: isPhysicalRegister() reports false for
  NoRegister anyway
- Do not repeat function name in documentation comment.
- Do not repeat documentation comment in implementation when we already
  have one at the declaration.
- Factor some common subexpressions out.
- Change file comments to use doxygen syntax.

llvm-svn: 274194

Add an explicit overload to BuildMI for MachineInstr& to deal with
insertions inside of instruction bundles.

- Use it to re-implement MachineInstr* to give it coverage.

- Document how the overload for MachineBasicBlock::instr_iterator
  differs from that for MachineBasicBlock::iterator (the previous
  (implicit) overload for MachineInstr&).

- Add a comment explaining why the MachineInstr& and MachineInstr*
  overloads don't universally forward to the
  MachineBasicBlock::instr_iterator overload.

Thanks to Justin for noticing the API quirk.  While this doesn't fix any
known bugs -- all uses of BuildMI with a MachineInstr& were previously
using MachineBasicBlock::iterator -- it protects against future bugs.

llvm-svn: 274193

llvm-svn: 274192

This function is already a bit too long, and I'm about to make it worse.

llvm-svn: 274191

This is mostly a mechanical change to make TargetInstrInfo API take
MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator)
when the argument is expected to be a valid MachineInstr.  This is a
general API improvement.

Although it would be possible to do this one function at a time, that
would demand a quadratic amount of churn since many of these functions
call each other.  Instead I've done everything as a block and just
updated what was necessary.

This is mostly mechanical fixes: adding and removing `*` and `&`
operators.  The only non-mechanical change is to split
ARMBaseInstrInfo::getOperandLatencyImpl out from
ARMBaseInstrInfo::getOperandLatency.  Previously, the latter took a
`MachineInstr*` which it updated to the instruction bundle leader; now,
the latter calls the former either with the same `MachineInstr&` or the
bundle leader.

As a side effect, this removes a bunch of MachineInstr* to
MachineBasicBlock::iterator implicit conversions, a necessary step
toward fixing PR26753.

Note: I updated WebAssembly, Lanai, and AVR (despite being
off-by-default) since it turned out to be easy.  I couldn't run tests
for AVR since llc doesn't link with it turned on.

llvm-svn: 274189

llvm-svn: 274188

- Use range based for
- Use the more common variable names MBB and MF for
  MachineBasicBlock/MachineFunction variables.
- Add a few const modifiers

llvm-svn: 274187

llvm-svn: 274186

The NewArchiveIterator class has a problem: it requires too much context. Any
memory buffers added to the archive must be stored within an Archive::Member,
which must have an associated Archive. This makes it harder than necessary
to create new archive members (or new archives entirely) from scratch using
memory buffers.

This patch replaces NewArchiveIterator with a NewArchiveMember class that
stores just the memory buffer and the information that goes into the archive
member header.

Differential Revision: http://reviews.llvm.org/D21721

llvm-svn: 274183

llvm-svn: 274182

This matches more closely the rest of the variables in LLVMConfig.cmake which
shed the _CONFIG_ part of their names.

llvm-svn: 274175

This makes it possible to e.g copy a report to another filesystem.

llvm-svn: 274173

This fixes an issue where occurrence counts would be unexpectedly
reset when parsing different parts of a command line multiple
times.

**ORIGINAL COMMIT MESSAGE**

This allows command line tools to use syntaxes like the following:

      llvm-foo.exe command1 -o1 -o2
      llvm-foo.exe command2 -p1 -p2

Where command1 and command2 contain completely different sets of
valid options.  This is backwards compatible with previous uses
of llvm cl which did not support subcommands, as any option
which specifies no optional subcommand (e.g. all existing
code) goes into a special "top level" subcommand that expects
dashed options to appear immediately after the program name.
For example, code which is subcommand unaware would generate
a command line such as the following, where no subcommand
is specified:

      llvm-foo.exe -q1 -q2

The top level subcommand can co-exist with actual subcommands,
as it is implemented as an actual subcommand which is searched
if no explicit subcommand is specified.  So llvm-foo.exe as
specified above could be written so as to support all three
aforementioned command lines simultaneously.

There is one additional "special" subcommand called AllSubCommands,
which can be used to inject an option into every subcommand.
This is useful to support things like help, so that commands
such as:

      llvm-foo.exe --help
      llvm-foo.exe command1 --help
      llvm-foo.exe command2 --help

All work and display the help for the selected subcommand
without having to explicitly go and write code to handle each
one separately.

This patch is submitted without an example of anything actually
using subcommands, but a followup patch will convert the
llvm-pdbdump tool to use subcommands.

Reviewed By: beanz

llvm-svn: 274171

The change causes llvm crash in some unoptimized builds.

llvm-svn: 274163

This is a fix for PR27842.

An IR-level implementation of stack coloring tailored to work with
SafeStack. It is a bit weaker than the MI implementation in that it
does not the "lifetime start at first access" logic. This can be
improved in the future.

This patch also replaces the naive implementation of stack frame
layout with a greedy algorithm that can split existing stack slots
and even fit small objects inside the alignment padding of other
objects.

llvm-svn: 274162

its clients.

This commit will break the next lld builds.  I’ll be committing the matching
change for lld next.

llvm-svn: 274160

Summary: Take advantage of FCmpInst::Predicate's bit pattern and handle (fcmp *, x, y) | (fcmp *, x, y) and (fcmp *, x, y) & (fcmp *, x, y) more consistently. Also fold more FCmpInst::FCMP_FALSE and FCmpInst::FCMP_TRUE to constants.

Currently InstCombine wrongly folds (fcmp ogt, x, y) | (fcmp ord, x, y) to (fcmp ogt, x, y); this patch also fixes that.

Reviewers: spatel

Subscribers: llvm-commits, iteratee, echristo

Differential Revision: http://reviews.llvm.org/D21775

llvm-svn: 274156

This removes some noise for D21775's test changes.

llvm-svn: 274155

Differential Revision:   http://reviews.llvm.org/D21846

llvm-svn: 274154

[x86] (PR15455) While (ins|outs)[bwld] instructions do not take %dx as a
memory operand, various unofficial references do and objdump
disassembles to this format. Extend special treatment of
similar (in|out)[bwld] operations.

Reviewers: craig.topper, rnk, ab

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D18837

llvm-svn: 274152

This fixes pr28072.

The point, as Duncan pointed out, is that the file is already
partially linked by just reading it.

Long term I think the solution is to make metadata owned by the module
and then the linker will lazily read it and be in charge of all the
linking. Running a verifier in each input will defeat the lazy
loading, but will be legal.

Right now we are at the unfortunate position that to support odr
merging we cannot verify the inputs, which mildly annoying (see test
update).

llvm-svn: 274148

Summary: This adds tests for covering all cases that FoldAndOfFCmps and FoldOrOfFCmps handle.

Reviewers: spatel

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D21844

llvm-svn: 274144

I'm planning on extending these two tests with checks that validate
html coverage reports. Make it easier to extend them by not using a
prefix called "CHECK".

llvm-svn: 274143

llvm-svn: 274142

llvm-svn: 274141

[LLVMConfig.cmake.in] Create a new variable LLVM_CONFIG_EXPORTED_TARGETS that contains the list of all targets exported via LLVMExports.cmake.

llvm-svn: 274140

llvm-svn: 274139

When lowering two blended PACKUS, we used to disregard the types
of the PACKUS inputs, indiscriminately generating a v16i8 PACKUS.

This leads to non-selectable things like:
    (v16i8 (PACKUS (v4i32 v0), (v4i32 v1)))

Instead, check that the PACKUSes have the same type, and use that
as the final result type.

llvm-svn: 274138

Some bots do not configure llvm with zlib enabled. Should fix:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/15571

llvm-svn: 274137

llvm-svn: 274136

In -output-dir mode, file reports are placed into a "coverage"
directory. If filenames in the coverage mapping contain "..", they might
escape out of this directory.

Fix the problem by removing ".." from source filenames (expand the path
component).

llvm-svn: 274135

This gets rid of the memory fence in the hot path (dereferencing the
ManagedStatic), trading for an extra mutex lock in the cold path (when
the ManagedStatic was uninitialized). Since this only happens on the
first accesses it shouldn't matter much. On strict architectures like
x86 this removes any atomic instructions from the hot path.

Also remove the tsan annotations, tsan knows how standard atomics work
so they should be unnecessary now.

llvm-svn: 274131

They are created by ld64 since OS X 10.5.

llvm-svn: 274130

llvm-svn: 274129

Patch by Visoiu Mistrih Francis.

Differential Revision: http://reviews.llvm.org/D21819

llvm-svn: 274128

llvm-svn: 274127

llvm-svn: 274124

llvm-svn: 274115

These are not used by CodeGen yet - ISD combiners creating the new node
will come in subsequent patches.

llvm-svn: 274108

This reverts commit 520a8298d8ef676b5da617ba3d2c7fa37381e939 (r273055).

This is breaking stage2 instrumented builds with "malformed coverage
data" errors.

llvm-svn: 274106