Targets can now add CalleeSavedRegs defs to their *CallingConv.td file.
TableGen will use this to create a *_SaveList array suitable for
returning from getCalleeSavedRegs() as well as a *_RegMask bit mask
suitable for returning from getCallPreservedMask().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148346 91177308-0d34-0410-b5e6-96231b3b80d8
Use information computed while inferring new register classes to emit
accurate, table-driven implementations of getMatchingSuperRegClass().
Delete the old manual, error-prone implementations in the targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146873 91177308-0d34-0410-b5e6-96231b3b80d8
This restores my karma after I added TRI::getSubClassWithSubReg().
Register constraints are applied 'backwards'. Starting from the
register class required by an instruction operand, the correct question
is: 'How can I constrain the super-register register class so all its
sub-registers satisfy the instruction constraint?' The
getMatchingSuperRegClass() hook answers that.
We never need to go 'forwards': Starting from a super-register register
class, what register class are the sub-registers in? The
getSubRegisterRegClass() hook did that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141258 91177308-0d34-0410-b5e6-96231b3b80d8
This function is used to constrain a register class to a sub-class that
supports the given sub-register index.
For example, getSubClassWithSubReg(GR32, sub_8bit) -> GR32_ABCD.
The function will be used to compute register classes when emitting
INSERT_SUBREG and EXTRACT_SUBREG nodes and for register class inflation
of sub-register operations.
The version provided by TableGen is usually adequate, but targets can
override.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141142 91177308-0d34-0410-b5e6-96231b3b80d8
When TableGen starts creating its own register classes, the synthesized
classes won't have a Record reference. All register classes must have a
name, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141081 91177308-0d34-0410-b5e6-96231b3b80d8
This uses less memory and it reduces the complexity of sub-class
operations:
- hasSubClassEq() and friends become O(1) instead of O(N).
- getCommonSubClass() becomes O(N) instead of O(N^2).
In the future, TableGen will infer register classes. This makes it
cheap to add them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140898 91177308-0d34-0410-b5e6-96231b3b80d8
This can happen in cases where TableGen generated asm matcher cannot check
whether a register operand is in the right register class. e.g. mem operands.
rdar://8204588
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136292 91177308-0d34-0410-b5e6-96231b3b80d8
This makes TargetRegisterClass slightly slower. Next step will be making contains faster.
Eventually TargetRegisterClass will be killed entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135835 91177308-0d34-0410-b5e6-96231b3b80d8
to MCRegisterInfo. Also initialize the mapping at construction time.
This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135424 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC decorates (and distinguishes) "const" in mangler. It brought linkage error between "extern const" declarations and definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135269 91177308-0d34-0410-b5e6-96231b3b80d8
Manage Inits in a FoldingSet. This provides several benefits:
- Memory for Inits is properly managed
- Duplicate Inits are folded into Flyweights, saving memory
- It enforces const-correctness, protecting against certain classes
of bugs
The above benefits allow Inits to be used in more contexts, which in
turn provides more dynamism to TableGen. This enhanced capability
will be used by the AVX code generator to a fold common patterns
together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134907 91177308-0d34-0410-b5e6-96231b3b80d8
This caused linker errors when linking both libLLVMX86Desc and libLLVMX86CodeGen
into a single binary (for example when building a monolithic libLLVM shared library).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133791 91177308-0d34-0410-b5e6-96231b3b80d8
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.
First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133782 91177308-0d34-0410-b5e6-96231b3b80d8
Targets that need to change the default allocation order should use the
AltOrders mechanism instead. See the X86 and ARM targets for examples.
The allocation_order_begin() and allocation_order_end() methods have been
replaced with getRawAllocationOrder(), and there is further support
functions in RegisterClassInfo.
It is no longer possible to insert arbitrary code into generated
register classes. This is a feature.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133332 91177308-0d34-0410-b5e6-96231b3b80d8
A register class can define AltOrders and AltOrderSelect instead of
defining method protos and bodies. The AltOrders lists can be defined
with set operations, and TableGen can verify that the alternative
allocation orders only contain valid registers.
This is currently an opt-in feature, and it is still possible to
override allocation_order_begin/end. That will not be true for long.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133320 91177308-0d34-0410-b5e6-96231b3b80d8
At the time I wrote this code (circa 2007), TargetRegisterInfo was using a std::set to perform these queries. Switching to the static hashtables was an obvious improvement, but in reality there's no reason to do anything other than scan.
With this change, total LLC time on a whole-program 403.gcc is reduced by approximately 1.5%, almost all of which comes from a 15% reduction in LiveVariables time. It also reduces the binary size of LLC by 86KB, thanks to eliminating a bunch of very large static tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133051 91177308-0d34-0410-b5e6-96231b3b80d8
Make the Elements vector private and expose an ArrayRef through
getOrder() instead. getOrder will eventually provide multiple
user-specified allocation orders.
Use the sorted member set for member and subclass tests. Clean up a lot
of ad hoc searches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133040 91177308-0d34-0410-b5e6-96231b3b80d8
Measure the worst case number of probes for a miss instead of the less
conservative number of probes required for an insertion.
Lower the limit to < 6 probes worst case.
This doubles the size of the ARM and X86 hash tables, other targets are
unaffected. LiveVariables runs 12% faster with this change.
<rdar://problem/9598545>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132999 91177308-0d34-0410-b5e6-96231b3b80d8
Make the hash tables as small as possible while ensuring that all
lookups can be done in less than 8 probes.
Cut the aliases hash table in half by only storing a < b pairs - it
is a symmetric relation.
Use larger multipliers on the initial hash function to ensure that it
properly covers the whole table, and to resolve some clustering in the
very regular ARM register bank.
This reduces the size of most of these tables by 4x - 8x. For instance,
the ARM tables shrink from 48 KB to 8 KB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132888 91177308-0d34-0410-b5e6-96231b3b80d8
The constant hash tables for sub-registers and overlaps are generated
the same way, so extract a function to generate and print the hash
table.
Also use the information computed by CodeGenRegisters.cpp instead of the
locally data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132886 91177308-0d34-0410-b5e6-96231b3b80d8
Besides moving structural computations to CodeGenRegisters.cpp, this
also well-defines the order of these lists:
- Sub-register lists come from a pre-order traversal of the graph
defined by the SubRegs lists in the .td files.
- Super-register lists are topologically ordered so no register comes
before any of its sub-registers. When the sub-register graph is not a
tree, independent super-registers appear in numerical order.
- Lists of overlapping registers are ordered according to register
number.
This reverses the order of the super-regs lists, but nobody was
depending on that. The previous order of the overlaps lists was odd, and
it may have depended on the precise behavior of std::stable_sort.
The old computations are still there, but will be removed shortly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132881 91177308-0d34-0410-b5e6-96231b3b80d8
Create a new CodeGenRegBank class that will eventually hold all the code
that computes the register structure from Records.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132849 91177308-0d34-0410-b5e6-96231b3b80d8