safely proven not to have been clobbered. No small test case possible.

llvm-svn: 147751

llvm-svn: 147733

Add some DAG combines for SUBC/SUBE. If nothing uses the carry/borrow out of subc, turn it into a sub. Turn (subc x, x) into 0 with no borrow. Turn (subc x, 0) into x with no borrow. Turn (subc -1, x) into (xor x, -1) with no borrow. Turn sube with no borrow in into subc.

llvm-svn: 147728

Reserved registers don't have proper live ranges, their LiveInterval
simply has a snippet of liveness for each def.  Virtual registers with a
single value that is a copy of a reserved register (typically %esp) can
be coalesced with the reserved register if the live range doesn't
overlap any reserved register defs.

When coalescing with a reserved register, don't modify the reserved
register live range.  Just leave it as a bunch of dead defs.  This
eliminates quadratic coalescer behavior in i386 functions with many
function calls.

PR11699

llvm-svn: 147726

llvm-svn: 147725

up so branch folding pass can't use the scavenger. :-(  This doesn't breaks
anything currently. It just means targets which do not carefully update kill
markers cannot run post-ra scheduler (not new, it has always been the case).

We should fix this at some point since it's really hacky.

llvm-svn: 147719

opportunities that only present themselves after late optimizations
such as tail duplication .e.g.
## BB#1:
        movl    %eax, %ecx
        movl    %ecx, %eax
        ret

The register allocator also leaves some of them around (due to false
dep between copies from phi-elimination, etc.)

This required some changes in codegen passes. Post-ra scheduler and the
pseudo-instruction expansion passes have been moved after branch folding
and tail merging. They were before branch folding before because it did
not always update block livein's. That's fixed now. The pass change makes
independently since we want to properly schedule instructions after
branch folding / tail duplication.

rdar://10428165
rdar://10640363

llvm-svn: 147716

llvm-svn: 147703

llvm-svn: 147696

to bleed from the eyes.

llvm-svn: 147695

llvm-svn: 147694

llvm-svn: 147693

llvm-svn: 147682

lldb testsuite.

rdar://10652330

llvm-svn: 147673

the debug type accelerator tables to contain the tag and a flag
stating whether or not a compound type is a complete type.

rdar://10652330

llvm-svn: 147651

llvm-svn: 147618

llvm-svn: 147615

llvm-svn: 147605

a combined-away node and the result of the combine isn't substantially
smaller than the input, it's just canonicalized. This is the first part
of a significant (7%) performance gain for Snappy's hot decompression
loop.

llvm-svn: 147604

Minor postra scheduler cleanup. It could result in more precise antidependence latency on ARM in exceedingly rare cases.

llvm-svn: 147594

The register allocators don't currently support adding reserved
registers while they are running.  Extend the MRI API to keep track of
the set of reserved registers when register allocation started.

Target hooks like hasFP() and needsStackRealignment() can look at this
set to avoid reserving more registers during register allocation.

llvm-svn: 147577

Allow vector shuffle normalizing to use concat vector even if the sources are commuted in the shuffle mask.

llvm-svn: 147527

llvm-svn: 147525

Before we'd get:

$ clang t.c 
fatal error: error in backend: Invalid operand for inline asm constraint 'i'!

Now we get:

$ clang t.c
t.c:16:5: error: invalid operand for inline asm constraint 'i'!
    "movq         (%4), %%mm0\n"
    ^

Which at least gets us the inline asm that is the problem.

llvm-svn: 147502

This can only happen if the set of reserved registers changes during
register allocation.

<rdar://problem/10625436>

llvm-svn: 147486

llvm-svn: 147484

Remove the restriction that target intrinsics can only involve legal types.  Targets can perfects well support intrinsics on illegal types, as long as they are prepared to perform custom expansion during type legalization.  For example, a target where i64 is illegal might still support the i64 intrinsic operation using pairs of i32's.  ARM already does some expansions like this for non-intrinsic operations.

llvm-svn: 147472

llvm-svn: 147471

llvm-svn: 147454

The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.

The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.

I added a special test that checks vector shuffle on win32.

llvm-svn: 147445

llvm-svn: 147400

The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.

The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.

I added a special test that checks vector shuffle on win32.

llvm-svn: 147399

Promotion of the mask operand needs to be done using PromoteTargetBoolean, and not padded with garbage.

llvm-svn: 147309

Make sure DAGCombiner doesn't introduce multiple loads from the same memory location.  PR10747, part 2.

llvm-svn: 147283

llvm-svn: 147272

llvm-svn: 147197

llvm-svn: 147127

Fixes <rdar://problem/10584116>

llvm-svn: 147125

don't get any serious benefit there.

llvm-svn: 147101

- Add some constantness.

llvm-svn: 147090