registers based on dynamic conditions. For example, X86 EBP/RBP, when used as
frame register has to be spilled in the first fixed object. It should inform
PEI this so it doesn't get allocated another stack object. Also, it should not
be spilled as other callee-saved registers but rather its spilling and restoring
are being handled by emitPrologue and emitEpilogue. Avoid spilling it twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75116 91177308-0d34-0410-b5e6-96231b3b80d8
This stops gcc warning about possible uses of an uninitialized
value when compiling with assertions turned off.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74775 91177308-0d34-0410-b5e6-96231b3b80d8
Implement LowerFORMAL_ARGUMENTS_SVR4().
Implement LowerCALL_SVR4().
Add support for split arguments.
Implement by value parameter passing for aggregates.
Add support for variable argument lists.
Create the spill area for argument registers of variable argument functions no longer at a fixed offset.
Make sure callee saved registers are spilled to the correct stack offsets.
Change allocation order of non-volatile floating-point registers.
Add VRSAVE to the list of callee-saved registers, add CallConvLowering for vararg calls.
Add support for variable argument calls with Vector arguments.
Add support for VR and VRSAVE save area, improve allocation order for non-volatile vector registers.
Stop creating illegal i8 values in LowerVASTART().
Add memory access width hints.
Make sure to reserve space on the stack for the frame pointer.
When using the SVR4 ABI, reserve r13 for the Small Data Area pointer.
Assure that the frame pointer is spilled to the correct location on the stack.
Some FP registers were not marked as volatile.
Make sure the i64 words from a long double are passed either both in registers or both on the stack.
Only put integer arguments in registers which are not marked with the inreg flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74765 91177308-0d34-0410-b5e6-96231b3b80d8
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
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 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
C bindings. Change all the backend "Initialize" functions to have C linkage.
Change the "llvm/Config/Targets.def" header to use C-style comments to avoid
compile warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74026 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
LEA64_32r, eliminating a bunch of modifier logic stuff on addr modes.
Implement support for printing mbb labels as operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73817 91177308-0d34-0410-b5e6-96231b3b80d8
into DarwinTargetAsmInfo.cpp. The remaining differences should
be evaluated. It seems strange that x86/arm has .zerofill but ppc
doesn't, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73742 91177308-0d34-0410-b5e6-96231b3b80d8
- Register allocator should resolve the second part of the hint (register number) before passing it to the target since it knows virtual register to physical register mapping.
- More fixes to get ARM load / store double word working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73671 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
Emission for globals, using the correct data sections
Function alignment can be computed for each target using TargetELFWriterInfo
Some small fixes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73201 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the IndexedModeAction representation to remove the
limitation on the number of value types in MVT. This limitation
prevents us from specifying AVX types.
Prior to this change IndexedModActions was represented as follows...
uint64_t IndexedModeActions[2][ISD::LAST_INDEXED_MODE];
the first dimension was used to represent loads, then stores. This
imposed a limitation of 32 on the number of value types that could be
handled with this method. The value type was used to shift the two bits
into and out of the approprate bits in the uint64_t.
With this change the array is now represented as ...
uint8_t IndexedModeActions[MVT::LAST_VALUETYPE][2][ISD::LAST_INDEXED_MODE];
Takes more space but removes the limitation on MVT::LAST_VALUETYPE. The
first dimension is now the value_type for the reference. The second
dimension is the load [0] vs. store[1]. The third dimension represents
the various modes for load store. Accesses are now direct, no shifting
or masking.
There are other limitations that need to be removed, so that
MVT::LAST_VALUETYPE can be greater than 32. This is merely the first
step towards that goal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73104 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the IndexedModeAction representation to remove the
limitation on the number of value types in MVT. This limitation
prevents us from specifying AVX types.
Prior to this change IndexedModActions was represented as follows...
uint64_t IndexedModeActions[2][ISD::LAST_INDEXED_MODE];
the first dimension was used to represent loads, then stores. This
imposed a limitation of 32 on the number of value types that could be
handled with this method. The value type was used to shift the two bits
into and out of the approprate bits in the uint64_t.
With this change the array is now represented as ...
uint8_t IndexedModeActions[MVT::LAST_VALUETYPE][2][ISD::LAST_INDEXED_MODE];
Takes more space but removes the limitation on MVT::LAST_VALUETYPE. The
first dimension is now the value_type for the reference. The second
dimension is the load [0] vs. store[1]. The third dimension represents
the various modes for load store. Accesses are now direct, no shifting
or masking.
There are other limitations that need to be removed, so that
MVT::LAST_VALUETYPE can be greater than 32. This is merely the first
step towards that goal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73102 91177308-0d34-0410-b5e6-96231b3b80d8
ABI. The missing piece is support for putting "homogeneous aggregates"
into registers.
Patch by Sandeep Patel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73095 91177308-0d34-0410-b5e6-96231b3b80d8
other operators. For the rare cases where a list type cannot be
deduced, provide a []<type> syntax, where <type> is the list element
type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73078 91177308-0d34-0410-b5e6-96231b3b80d8
Update code generator to use this attribute and remove NoImplicitFloat target option.
Update llc to set this attribute when -no-implicit-float command line option is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72959 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72957 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72894 91177308-0d34-0410-b5e6-96231b3b80d8
ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag. Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.
Most targets will still produce a Flag-setting target-dependent
version when selection is done. X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc. This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted. All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly. The
same can be done on other targets.
The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72707 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72507 91177308-0d34-0410-b5e6-96231b3b80d8
