initialization of all targets (InitializeAllTargets.h) or assembler
printers (InitializeAllAsmPrinters.h). This is a step toward the
elimination of relinked object files, so that we can build normal
archives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73543 91177308-0d34-0410-b5e6-96231b3b80d8
to ignore readonly calls, and factor it out of instcombine so
that it can be used by other passes. Patch by Frits van Bommel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73506 91177308-0d34-0410-b5e6-96231b3b80d8
failures.
To support this, add some utility functions to Type to help support
vector/scalar-independent code. Change ConstantInt::get and
ConstantFP::get to support vector types, and add an overload to
ConstantInt::get that uses a static IntegerType type, for
convenience.
Introduce a new getConstant method for ScalarEvolution, to simplify
common use cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73431 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
is that, for functions whose bodies are entirely guarded by an if-statement, it
can be profitable to pull the test out of the callee and into the caller.
This code has had some cursory testing, but still has a number of known issues
on the LLVM test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73338 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
