never kept after splitting.

Keeping the original interval made sense when the split region doesn't modify
the register, and the original is spilled. We can get the same effect by
detecting reloaded values when spilling around copies.

llvm-svn: 115695

llvm-svn: 115694

not getting marked as mayStore.  This fixes llvm-gcc bootstrap.

llvm-svn: 115693

llvm-svn: 115692

llvm-svn: 115691

 X86InstrCMovSetCC.td |  200 ++++++---------------------------------------------
 1 file changed, 27 insertions(+), 173 deletions(-)

llvm-svn: 115689

llvm-svn: 115687

llvm-svn: 115686

gross hack (having the asmmatcher handle the alias).

llvm-svn: 115685

llvm-svn: 115684

Previously, compiler warned only if it was unsafe if types
did not match. Fixes // rdar: //7933061

llvm-svn: 115683

llvm-svn: 115671

llvm-svn: 115670

the right places.  X86Instr64bit.td now dies, long live x86-64!

llvm-svn: 115669

a EH-only cleanup as part of a fallthrough branch-through.  That this happens
for this test case is actually a separate bug.

llvm-svn: 115668

llvm-svn: 115667

erasing it from the visited set. That ensures we create the right phi defs.

llvm-svn: 115666

Insert copy after defining instruction.

Fix LiveIntervalMap::extendTo to properly handle live segments starting before
the current basic block.

Make sure the open live range is extended to the inserted copy's use slot.

llvm-svn: 115665

llvm-svn: 115664

llvm-svn: 115663

buildbots, since I seem to have blown up the build master :(

llvm-svn: 115662

llvm-svn: 115660

so that expressions can use them.

llvm-svn: 115658

llvm-svn: 115657

llvm-svn: 115656

llvm-svn: 115655

Add a test class to call lldb 'disassemble -n function' command on each call frame when stopped on C's ctor.
This is not a long running test so it shall always be exercised.

llvm-svn: 115653

Add a utility function to lldbtest.py to get the native pointer size of the host os.

llvm-svn: 115652

llvm-svn: 115650

llvm-svn: 115649

following amusing sequence:
  - AST writing schedules writing a type X* that it had never seen
  before
  - AST writing starts writing another declaration, ends up
  deserializing X* from a prior AST file. Now we have two type IDs for
  the same type!
  - AST writer tries to write X*. It only has the lower-numbered ID
  from the the prior AST file, so references to the higher-numbered ID
  that was scheduled for writing go off into lalaland.

To fix this, keep the higher-numbered ID so we end up writing the type
twice. Since this issue occurs so rarely, and type records are
generally rather small, I deemed this better than the alternative: to
keep a separate mapping from the higher-numbered IDs to the
lower-numbered IDs, which we would end up having to check whenever we
want to deserialize any type.

Fixes <rdar://problem/8511624>, I think.

llvm-svn: 115647

addressing mode from four to five.

llvm-svn: 115645

block descriptor for outer block was missing even though
the block was importing objects into its inner blocks.
//rdar://84995992

llvm-svn: 115644

isInSymtab and isLocal logic in the two loops don't get easily out of sync.

llvm-svn: 115643

llvm-svn: 115642

llvm-svn: 115641

llvm-svn: 115640

llvm-svn: 115639

Fix handling of the 'Invalid' argument in SourceManager's methods (patch by Dean Sturtevant, reviewed by chandlerc and Sebastian Redl).

llvm-svn: 115638

llvm-svn: 115636