With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put
into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.
The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74764 91177308-0d34-0410-b5e6-96231b3b80d8
Note, isUndef marker must be placed even on implicit_def def operand or else the scavenger will not ignore it. This is necessary because -O0 path does not use liveintervalanalysis, it treats implicit_def just like any other def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74601 91177308-0d34-0410-b5e6-96231b3b80d8
- This more or less amounts to a revert of r65379. I'm curious to know what
happened that caused this variable to become unused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74579 91177308-0d34-0410-b5e6-96231b3b80d8
have the alignment be calculated up front, and have the back-ends obey whatever
alignment is decided upon.
This allows for future work that would allow for precise no-op placement and the
like.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74564 91177308-0d34-0410-b5e6-96231b3b80d8
The register allocator, when it allocates a register to a virtual register defined by an implicit_def, can allocate any physical register without worrying about overlapping live ranges. It should mark all of operands of the said virtual register so later passes will do the right thing.
This is not the best solution. But it should be a lot less fragile to having the scavenger try to track what is defined by implicit_def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74518 91177308-0d34-0410-b5e6-96231b3b80d8
the SelectionDAG::getGlobalAddress function properly looks through
aliases to determine thread-localness, but then passes the GV* down
to GlobalAddressSDNode::GlobalAddressSDNode which does not. Instead
of passing down isTarget, just pass down the predetermined node
opcode. This fixes some assertions with out of tree changes I'm
working on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74325 91177308-0d34-0410-b5e6-96231b3b80d8
The OpActions array had a limit of 32 value types, so change it to use
MVT::MAX_ALLOWED_VALUETYPE in its declaration and change the accesses to
this array to work with a VT.getSimpleVT() that is larger than 32.
Also, add a comment to the place where MVT::MAX_ALLOWED_VALUETYPE is
defined indicating that it must be a multiple of 32.
This is part of the work allow MVT::LAST_VALUETYPE be greater than 32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74130 91177308-0d34-0410-b5e6-96231b3b80d8
This change doubles the allowable value for MVT::LAST_VALUETYPE. It does
this by doing several things.
1. Introduces MVT::MAX_ALLOWED_LAST_VALUETYPE which in this change has a
value of 64. This value contains the current maximum for the
MVT::LAST_VALUETYPE.
2. Instead of checking "MVT::LAST_VALUETYPE <= 32", all of those uses
now become "MVT::LAST_VALUETYPE <= MVT::MAX_ALLOWED_LAST_VALUETYPE"
3. Changes the dimension of the ValueTypeActions from 2 elements to four
elements and adds comments ahead of the declaration indicating the it is
"(MVT::MAX_ALLOWED_LAST_VALUETYPE/32) * 2". This at least lets us find
what is affected if and when MVT::MAX_ALLOWED_LAST_VALUETYPE gets
changed.
4. Adds initializers for the new elements of ValueTypeActions.
This does NOT add any types in MVT. That would be done separately.
This doubles the size of ValueTypeActions from 64 bits to 128 bits and
gives us the freedom to add more types for AVX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74110 91177308-0d34-0410-b5e6-96231b3b80d8
a bunch of code from all the targets, and eliminates nondeterministic
ordering of directives being emitted in the output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74096 91177308-0d34-0410-b5e6-96231b3b80d8
Support for .text relocations, implementing TargetELFWriter overloaded methods for x86/x86_64.
Use a map to track global values to their symbol table indexes
Code cleanup and small fixes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73894 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73381 91177308-0d34-0410-b5e6-96231b3b80d8
