expand to multiple basic blocks, in which case fast-isel
needs to informed of which block to use as it resumes
inserting instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57040 91177308-0d34-0410-b5e6-96231b3b80d8
was setting kill flags on tied uses in two-address instructions.
The kill flags were causing the allocator to think it could
allocate the use and its tied def in different registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57039 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, just create one, and make sure everything that needs
it can access it. Previously most of the SelectionDAGISel
subclasses all had their own TargetLowering object, which was
redundant with the TargetLowering object in the TargetMachine
subclasses, except on Sparc, where SparcTargetMachine
didn't have a TargetLowering object. Change Sparc to work
more like the other targets here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57016 91177308-0d34-0410-b5e6-96231b3b80d8
this handling to work properly for modifying stub functions, relocations
back to entry points after JIT compilation, etc..
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57013 91177308-0d34-0410-b5e6-96231b3b80d8
than the type an i1 is promoted to (eg: i8). Account
for this. Noticed by Tilmann Scheller on CellSPU; he
will hopefully take care of fixing this in LegalizeDAG
and adding a testcase!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56997 91177308-0d34-0410-b5e6-96231b3b80d8
can be used when deciding if a block can transfer control to another
via a fall-through instead of a branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56968 91177308-0d34-0410-b5e6-96231b3b80d8
the same source. I don't know what I was thinking when I wrote this originally.
Note: There's probably a more efficient way to do this, but I need to think about it some more, and about what determinism
guarantees need to be present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56964 91177308-0d34-0410-b5e6-96231b3b80d8
local register allocator's physreg liveness doesn't recognize subregs,
so it doesn't know that defs of %ecx that are immediately followed by
uses of %cl aren't dead. This comes up due to the way fast-isel emits
shift instructions.
This is a temporary workaround. Arguably, local regalloc should
handle subreg references correctly. On the other hand, perhaps
fast-isel should use INSERT_SUBREG instead of just assigning to the
most convenient super-register of %cl when lowering shifts.
This fixes MultiSource/Benchmarks/MallocBench/espresso,
MultiSource/Applications/hexxagon, and others, under -fast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56947 91177308-0d34-0410-b5e6-96231b3b80d8
a constant vector ("{0x123, 0x456}" syntax). The fix is to simplify the
_mm_srli_si128 macro, and move the "* 8" from the macro into the compiler
back-end. I can't change the existing __builtins because so many people are
using them :-(."
Patch by Stuart Hastings!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56944 91177308-0d34-0410-b5e6-96231b3b80d8
This allows the 64-bit forms to use+def RSP instead of ESP. This
doesn't fix any real bugs today, but it is more precise and it
makes the debug dumps on x86-64 look more consistent.
Also, add some comments describing the CALL instructions' physreg
operand uses and defs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56925 91177308-0d34-0410-b5e6-96231b3b80d8
pointer bitcasts and GEP's", and centralize the
logic in Value::getUnderlyingObject. The
difference with stripPointerCasts is that
stripPointerCasts only strips GEPs if all
indices are zero, while getUnderlyingObject
strips GEPs no matter what the indices are.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56922 91177308-0d34-0410-b5e6-96231b3b80d8