Make the renumbering correct in the face of deleted instructions that have been removed from the LiveIntervals maps.

llvm-svn: 51714

llvm-svn: 51712

llvm-svn: 51709

llvm-svn: 51708

llvm-svn: 51707

cases due to an isel deficiency already noted in
lib/Target/X86/README.txt, but they can be matched in this fold-call.ll
testcase, for example.

This is interesting mainly because it exposes a tricky tblgen bug;
tblgen was incorrectly computing the starting index for variable_ops
in the case of a complex pattern.

llvm-svn: 51706

function to flush a specified std::ostream.

llvm-svn: 51705

llvm-svn: 51704

- #include ExprObjC.h in many places

llvm-svn: 51703

llvm-svn: 51701

definitions. This adds a new construct, "discard", for indicating
that a named node in the input matching pattern is to be discarded,
instead of corresponding to a node in the output pattern. This
allows tblgen to know where the arguments for the varaible_ops are
supposed to begin.

This fixes "rdar://5791600", whatever that is ;-).

llvm-svn: 51699

llvm-svn: 51698

llvm-svn: 51697

memmove to a more plausible value, now that it's actually being used.

llvm-svn: 51696

llvm-svn: 51695

llvm-svn: 51694

llvm-svn: 51693

llvm-svn: 51692

Renumbering needs to account for instruction slot offsets when performing lookups in the index maps.

llvm-svn: 51691

llvm-svn: 51689

llvm-svn: 51688

llvm-svn: 51687

llvm-svn: 51686

llvm-svn: 51685

llvm-svn: 51683

constant expressions.

llvm-svn: 51682

unsigned because it's possible (at least in theory) to have
have both positive and negative pointers pointing to the same object.

llvm-svn: 51681

llvm-svn: 51680

in unions (we don't want to do the union-specific bitcast for 
bit-fields).

llvm-svn: 51678

expressions.

llvm-svn: 51677

alignment and alignment attributes.

llvm-svn: 51676

emit incomplete types, because they crash llc, and always use the 
logical location as the current location so we don't crash doing invalid 
queries on CurLoc.

llvm-svn: 51675

This change makes clang generate the same thing as llvm-gcc.

llvm-svn: 51674

nothing fundamentally wrong with it. Emitting unpacked structs where 
possible is more work for almost no practical benefit.  We'll probably 
want to fix it at some point anyway, but it's low priority.

The issue with long double in particular is that LLVM thinks an X86 long
double is 10 bytes, while clang considers it for all purposes to be
either 12 or 16 bytes, depending on the platform, even in a packed
struct.

llvm-svn: 51673

llvm-svn: 51672

Dhrystone introduced by its removal.

llvm-svn: 51669

the one case that ADCE catches that normal DCE doesn't: non-induction variable
loop computations.

This implementation handles this problem without using postdominators.

llvm-svn: 51668

llvm-svn: 51667

llvm-svn: 51666

llvm-svn: 51665