enabled for all targets. Non-X86 targets should not have this behavior
enabled by default.
Joerg, if you would like to resubmit with the behavior conditionalized to be
X86-ELF only, that's fine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126336 91177308-0d34-0410-b5e6-96231b3b80d8
events on the thread and wait until a resource is ready to event. The vector
of the resource that is ready is returned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126320 91177308-0d34-0410-b5e6-96231b3b80d8
it to ignore valid uses of FS and GS as additional
base registers in address computations. Added a test
case for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126302 91177308-0d34-0410-b5e6-96231b3b80d8
The previous codegen for the slow path (when values are in VFP / NEON
registers) was incorrect if the source is NaN.
The new codegen uses NEON vbsl instruction to copy the sign bit. e.g.
vmov.i32 d1, #0x80000000
vbsl d1, d2, d0
If NEON is not available, it uses integer instructions to copy the sign bit.
rdar://9034702
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126295 91177308-0d34-0410-b5e6-96231b3b80d8
When a large live range is evicted, it will usually be split when it comes
around again. By deferring evicted live ranges, the splitting happens at a time
when the interference pattern is more realistic. This prevents repeated
splitting and evictions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126282 91177308-0d34-0410-b5e6-96231b3b80d8
Use interval sizes instead of spill weights to determine if it is legal to evict
interference. A smaller interval can evict interference if all interfering live
ranges are larger.
Allow multiple interferences to be evicted as along as they are all larger than
the live range being allocated.
Spill weights are still used to select the preferred eviction candidate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126276 91177308-0d34-0410-b5e6-96231b3b80d8
This is based on the observation that long live ranges are more difficult to
allocate, so there is a better chance of solving the puzzle by handling the big
pieces first. The allocator will evict and split long alive ranges when they get
in the way.
RABasic is still using spill weights for its priority queue, so the interface to
the queue has been virtualized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126259 91177308-0d34-0410-b5e6-96231b3b80d8
share entries. Add a DenseSet to MachineConstantPool for the MachineCPVs that
it owns.
This will hopefully fix the MC/ARM/elf-reloc-01.ll failure on the leaks bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126218 91177308-0d34-0410-b5e6-96231b3b80d8
up by the dynamic linker, but it's better to use the correct instruction
to begin with.
Fixes rdar://9011034
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126176 91177308-0d34-0410-b5e6-96231b3b80d8
at phis. This enables us to eliminate a lot of pointless zexts during the DAGCombine
phase. This fixes <rdar://problem/8760114>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126170 91177308-0d34-0410-b5e6-96231b3b80d8
In other words, do not keep track of argument's location. The debugger (gdb) is not prepared to see line table entries for arguments. For the debugger, "second" line table entry marks beginning of function body.
This requires some coordination with debugger to get this working.
- The debugger needs to be aware of prolog_end attribute attached with line table entries.
- The compiler needs to accurately mark prolog_end in line table entries (at -O0 and at -O1+)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126155 91177308-0d34-0410-b5e6-96231b3b80d8
An original endpoint is an instruction that killed or defined the original live
range before any live ranges were split.
When splitting global live ranges, avoid creating local live ranges without any
original endpoints. We may still create global live ranges without original
endpoints, but such a range won't be split again, and live range splitting still
terminates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126151 91177308-0d34-0410-b5e6-96231b3b80d8
X86 instruction decode structure was being interpreted as
being in units of bits, although it is actually stored in
units of bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126147 91177308-0d34-0410-b5e6-96231b3b80d8
itself without going via a phi node then we could return false here in
spite of making a change. Also, tweak the comment because this method
can (and always could) return true without deleting the original phi node.
For example, if the phi node was used by a read-only invoke instruction
which is used by another phi node phi2 which is only used by and only uses
the invoke, then phi2 would be deleted but not the invoke instruction and
not the original phi node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126129 91177308-0d34-0410-b5e6-96231b3b80d8
