summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeGenRegisters.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Add a RegisterTuples class to Target.td and TableGen.Jakob Stoklund Olesen2011-06-201-1/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A RegisterTuples instance is used to synthesize super-registers by zipping together lists of sub-registers. This is useful for generating pseudo-registers representing register sequence constraints like 'two consecutive GPRs', or 'an even-odd pair of floating point registers'. The RegisterTuples def can be used in register set operations when building register classes. That is the only way of accessing the synthesized super-registers. For example, the ARM QQ register class of pseudo-registers could have been formed like this: // Form pairs Q0_Q1, Q2_Q3, ... def QQPairs : RegisterTuples<[qsub_0, qsub_1], [(decimate QPR, 2), (decimate (shl QPR, 1), 2)]>; def QQ : RegisterClass<..., (add QQPairs)>; Similarly, pseudo-registers representing '3 consecutive D-regs with wraparound' look like: // Form D0_D1_D2, D1_D2_D3, ..., D30_D31_D0, D31_D0_D1. def DSeqTriples : RegisterTuples<[dsub_0, dsub_1, dsub_2], [(rotl DPR, 0), (rotl DPR, 1), (rotl DPR, 2)]>; TableGen automatically computes aliasing information for the synthesized registers. Register tuples are still somewhat experimental. We still need to see how they interact with MC. llvm-svn: 133407
* Use the correct comparator to avoid depending on pointer values.Jakob Stoklund Olesen2011-06-181-1/+2
| | | | | | This should fix the Linux buildbots. llvm-svn: 133334
* Store CodeGenRegisters as pointers so they won't be reallocated.Jakob Stoklund Olesen2011-06-181-12/+10
| | | | | | | Reuse the CodeGenRegBank DenseMap in a few places that would build their own or use linear search. llvm-svn: 133333
* Remove MethodProtos/MethodBodies and allocation_order_begin/end.Jakob Stoklund Olesen2011-06-181-2/+0
| | | | | | | | | | | | | | 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. llvm-svn: 133332
* Provide AltOrders for specifying alternative allocation orders.Jakob Stoklund Olesen2011-06-181-0/+19
| | | | | | | | | | | | 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. llvm-svn: 133320
* Use a SetTheory instance to expand register lists in register classes.Jakob Stoklund Olesen2011-06-151-3/+6
| | | | | | | | This prepares tablegen to compute register lists from set theoretic dag expressions. This doesn't really make any difference as long as Target.td still declares RegisterClass::MemberList as [Register]. llvm-svn: 133043
* Give CodeGenRegisterClass a real sorted member set.Jakob Stoklund Olesen2011-06-151-20/+31
| | | | | | | | | | | 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. llvm-svn: 133040
* Move the list of register classes into CodeGenRegBank as well.Jakob Stoklund Olesen2011-06-151-0/+71
| | | | | | No functional change intended. llvm-svn: 133029
* Compute lists of sub-regs, super-regs, and overlapping regs.Jakob Stoklund Olesen2011-06-121-3/+99
| | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 132881
* Move the list of registers into CodeGenRegBank.Jakob Stoklund Olesen2011-06-111-10/+194
| | | | | | | Also move the sub-register index computations from RegisterInfoEmitter into CodeGenRegBank. llvm-svn: 132865
* Move some sub-register index calculations to CodeGenRegisters.cppJakob Stoklund Olesen2011-06-101-0/+27
| | | | | | | Create a new CodeGenRegBank class that will eventually hold all the code that computes the register structure from Records. llvm-svn: 132849
* Move TableGen's register bank classes to their own source file.Jakob Stoklund Olesen2011-06-091-0/+101
I'll be moving some more code there to gather all of the register-specific stuff in one place. Currently it is shared between CodeGenTarget and RegisterInfoEmitter. The plan is that CodeGenRegisters can compute the full register bank structure while RegisterInfoEmitter only will handle the printing part. llvm-svn: 132788
OpenPOWER on IntegriCloud