| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 73423
|
| |
|
|
| |
llvm-svn: 73404
|
| |
|
|
| |
llvm-svn: 73399
|
| |
|
|
|
|
|
|
|
| |
incomming chain of the RETURN node. The incomming chain must
be the outgoing chain of the CALL node. This causes the
backend to identify tail calls that are not tail calls. This
patch fixes this.
llvm-svn: 73387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Change register allocation hint to a pair of unsigned integers. The hint type is zero (which means prefer the register specified as second part of the pair) or entirely target dependent.
- Allow targets to specify alternative register allocation orders based on allocation hint.
Part 2.
- Use the register allocation hint system to implement more aggressive load / store multiple formation.
- Aggressively form LDRD / STRD. These are formed *before* register allocation. It has to be done this way to shorten live interval of base and offset registers. e.g.
v1025 = LDR v1024, 0
v1026 = LDR v1024, 0
=>
v1025,v1026 = LDRD v1024, 0
If this transformation isn't done before allocation, v1024 will overlap v1025 which means it more difficult to allocate a register pair.
- Even with the register allocation hint, it may not be possible to get the desired allocation. In that case, the post-allocation load / store multiple pass must fix the ldrd / strd instructions. They can either become ldm / stm instructions or back to a pair of ldr / str instructions.
This is work in progress, not yet enabled.
llvm-svn: 73381
|
| |
|
|
|
|
|
|
|
|
|
| |
consecutive addresses togther. This makes it easier for the post-allocation pass
to form ldm / stm.
This is step 1. We are still missing a lot of ldm / stm opportunities because
of register allocation are not done in the desired order. More enhancements
coming.
llvm-svn: 73291
|
| |
|
|
|
|
| |
live range may overlap another def of same register.
llvm-svn: 73255
|
| |
|
|
| |
llvm-svn: 73252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out of sync with regular cc.
The only difference between the tail call cc and the normal
cc was that one parameter register - R9 - was reserved for
calling functions through a function pointer. After time the
tail call cc has gotten out of sync with the regular cc.
We can use R11 which is also caller saved but not used as
parameter register for potential function pointers and
remove the special tail call cc on x86-64.
llvm-svn: 73233
|
| |
|
|
|
|
| |
(double def due to livevars)
llvm-svn: 73096
|
| |
|
|
| |
llvm-svn: 73025
|
| |
|
|
|
|
| |
converting from an MMX vector to an i64.
llvm-svn: 73024
|
| |
|
|
|
|
|
|
|
|
|
| |
on x86 to handle more cases. Fix a bug in said code that would cause it
to read past the end of an object. Rewrite the code in
SelectionDAGLegalize::ExpandBUILD_VECTOR to be a bit more general.
Remove PerformBuildVectorCombine, which is no longer necessary with
these changes. In addition to simplifying the code, with this change,
we can now catch a few more cases of consecutive loads.
llvm-svn: 73012
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 73009
|
| |
|
|
|
|
| |
types.
llvm-svn: 72993
|
| |
|
|
| |
llvm-svn: 72991
|
| |
|
|
|
|
|
|
| |
nodes for vectors with an i16 element type. Add an optimization for
building a vector which is all zeros/undef except for the bottom
element, where the bottom element is an i8 or i16.
llvm-svn: 72988
|
| |
|
|
| |
llvm-svn: 72987
|
| |
|
|
| |
llvm-svn: 72985
|
| |
|
|
|
|
|
| |
conversions for x86, like <2 x i32> -> <2 x float> and <4 x i16> ->
<4 x float>.
llvm-svn: 72983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
build vectors with i64 elements will only appear on 32b x86 before legalize.
Since vector widening occurs during legalize, and produces i64 build_vector
elements, the dag combiner is never run on these before legalize splits them
into 32b elements.
Teach the build_vector dag combine in x86 back end to recognize consecutive
loads producing the low part of the vector.
Convert the two uses of TLI's consecutive load recognizer to pass LoadSDNodes
since that was required implicitly.
Add a testcase for the transform.
Old:
subl $28, %esp
movl 32(%esp), %eax
movl 4(%eax), %ecx
movl %ecx, 4(%esp)
movl (%eax), %eax
movl %eax, (%esp)
movaps (%esp), %xmm0
pmovzxwd %xmm0, %xmm0
movl 36(%esp), %eax
movaps %xmm0, (%eax)
addl $28, %esp
ret
New:
movl 4(%esp), %eax
pmovzxwd (%eax), %xmm0
movl 8(%esp), %eax
movaps %xmm0, (%eax)
ret
llvm-svn: 72957
|
| |
|
|
|
|
| |
change no longer make sense after the coalescing changes we have made since then.
llvm-svn: 72955
|
| |
|
|
|
|
| |
a few lines later on.
llvm-svn: 72904
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
|
| |
|
|
|
|
|
| |
Update code generator to use this attribute and remove DisableRedZone target option.
Update llc to set this attribute when -disable-red-zone command line option is used.
llvm-svn: 72894
|
| |
|
|
|
|
| |
instead of the physical register it is allocated to. This resulted in virtual register(s) being added the live-in sets.
llvm-svn: 72890
|
| |
|
|
|
|
| |
unfortunate. But register allocator still has to add it to the live-in set of the use BB.
llvm-svn: 72888
|
| |
|
|
| |
llvm-svn: 72875
|
| |
|
|
|
|
| |
the code tried to use "push", which doesn't exist for XMM registers.)
llvm-svn: 72836
|
| |
|
|
| |
llvm-svn: 72830
|
| |
|
|
|
|
| |
MachineInstrBuilder::addReg() interface.
llvm-svn: 72826
|
| |
|
|
|
|
| |
DominatorTreeBase::Split.
llvm-svn: 72810
|
| |
|
|
|
|
|
|
| |
is assembly since Darwin assembler does not really support -static codeine.
I view this as a temporary workaround until the assembler / linker changes.
llvm-svn: 72806
|
| |
|
|
|
|
| |
clear the register kill operand marker and its kill ops information. However, the cleared operand may be a def of a super-register. Clear the kill ops info for the super-register's sub-registers as well.
llvm-svn: 72758
|
| |
|
|
| |
llvm-svn: 72757
|
| |
|
|
| |
llvm-svn: 72756
|
| |
|
|
|
|
|
| |
relocation model on x86-64. Higher level logic should override
the relocation model to PIC on x86_64-apple-darwin.
llvm-svn: 72746
|
| |
|
|
|
|
|
| |
addresses, involving Base values which do not have Pointer type.
This fixes PR4297.
llvm-svn: 72739
|
| |
|
|
| |
llvm-svn: 72734
|
| |
|
|
|
|
| |
the top 8 bits.
llvm-svn: 72618
|
| |
|
|
| |
llvm-svn: 72560
|
| |
|
|
| |
llvm-svn: 72558
|
| |
|
|
| |
llvm-svn: 72557
|
| |
|
|
| |
llvm-svn: 72539
|
| |
|
|
| |
llvm-svn: 72517
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
e.g.
orl $65536, 8(%rax)
=>
orb $1, 10(%rax)
Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.
llvm-svn: 72507
|
| |
|
|
| |
llvm-svn: 72485
|
| |
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.
llvm-svn: 72331
|
| |
|
|
|
|
|
|
|
| |
and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.
llvm-svn: 72328
|
| |
|
|
|
|
| |
running an extra DAGCombine pass which improves the code a bit.
llvm-svn: 72326
|