Nobody cared, StackSlotColoring scans the instructions to find used stack
slots.

llvm-svn: 144485

Most of this stuff was supporting the old deferred spill code insertion
mechanism.  Modern spillers just edit machine code in place.

llvm-svn: 144484

The information was only used by the register allocator in
StackSlotColoring.

llvm-svn: 144482

It was off by default.

The new register allocators don't have the problems that made it
necessary to reallocate registers during stack slot coloring.

llvm-svn: 144481

And there was much rejoicing.

llvm-svn: 144480

The very complicated VirtRegRewriter is going away.

llvm-svn: 144479

This is dead code, all register allocators use InlineSpiller.

llvm-svn: 144478

The current register allocators all use the inline spiller.

llvm-svn: 144477

It is worth noting that the old spiller would split live ranges around
basic blocks. The new spiller doesn't do that.

PBQP should do its own live range splitting with
SplitEditor::splitSingleBlock() if desired.  See
RAGreedy::tryBlockSplit().

llvm-svn: 144476

RegAllocGreedy has been the default for six months now.

Deleting RegAllocLinearScan makes it possible to also delete
VirtRegRewriter and clean up the spiller code.

llvm-svn: 144475

Counting the number of occurences of each opcode is not a useful test.

llvm-svn: 144474

Or maybe we are just getting lucky.

llvm-svn: 144473

llvm-svn: 144472

Filed PR11364 to track the problem.  Should the register allocator
eliminate dead code?

llvm-svn: 144471

This test was committed with a bugfix to RemoveCopyByCommutingDef, but
that optimization is no longer triggered by this test.

llvm-svn: 144470

This test is for a very specific LocalRewriter bug.  LocalRewriter is
going away.

llvm-svn: 144469

I don't think this test does what is was supposed to do, and
LocalRewriter is going away anyway.

llvm-svn: 144463

llvm-svn: 144462

llvm-svn: 144461

llvm-svn: 144460

This test doesn't expose the issue with RAGreedy.

I filed PR11363 to track the missing InlineSpiller feature.

llvm-svn: 144459

The test is checking that the output doesn't contains any 'mov '
strings. It does contain movl, though.

llvm-svn: 144458

Add more AVX2 shift lowering support. Move AVX2 variable shift to use patterns instead of custom lowering code.

llvm-svn: 144457

llvm-svn: 144454

llvm-svn: 144453

llvm-svn: 144452

methods but also class methods for Objective-C.

Clang emits Objective-C method names with '\1' at the
beginning, and the JIT has pre-existing logic to try
prepending a '\1' when searching a module for an
instance method (that is, a method whose name begins
with '-').  I simply extended it to do the same thing
when it encountered a class method (a method whose
name begins with '+').

llvm-svn: 144451

llvm-svn: 144449

llvm-svn: 144448

llvm-svn: 144447

llvm-svn: 144445

build: Attempt to rectify inconsistencies between CMake and LLVMBuild versions of explicit dependencies.
 - The hope is that we have a tool/test to verify these are accurate (and tight) soon.

llvm-svn: 144444

llvm-svn: 144442

instance and a concrete inlined instance are the use of DW_TAG_subprogram
instead of DW_TAG_inlined_subroutine and the who owns the tree.

We were also omitting DW_AT_inline from the abstract roots. To fix this,
make sure we mark abstract instance roots with DW_AT_inline even when
we have only out-of-line instances referring to them with DW_AT_abstract_origin.

FileCheck is not a very good tool for tests like this, maybe we should add
a -verify mode to llvm-dwarfdump.

llvm-svn: 144441

These immediate operands all use the same simple logic for rendering to
MCInst, so have them share the method for doing so.

llvm-svn: 144439

llvm-svn: 144438

Original commit msg: 'ARM assembly parsing for VST1 two-register encoding.'

llvm-svn: 144437

ARCH, which gets tested in many more contexts.

llvm-svn: 144434

Some cleanup and bulletproofing for node replacement in LegalizeDAG.  To maintain LegalizeDAG invariants, whenever we a node is replaced, we must attempt to delete it, and if it still
has uses after it is replaced (which can happen in rare cases due to CSE), we must revisit it.

llvm-svn: 144432

llvm-svn: 144431