[PATCH/RFC] Using the same RegisterClass names in TableGen and C++

[Richard Sandiford]

Ping

Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes:
> SystemZRegisterInfo.td has a RegisterClass-and-RegisterOperand pair for each
> conceptual register class.  The RegisterOperand is needed for custom parsing.
>
> RegisterClass and RegisterOperand are both DAGOperands, so the two definitions
> need to be distinct records with distinct names, rather than something like:
>
>   def Foo : RegisterClass <...>, RegisterOperand <...>;
>
> The C++ name of the RegisterClass is the TableGen name + "RegClass".
>
> While doing the port out-of-tree, I wanted to make as few changes
> to the generic code as possible, so I went for a system where the
> RegisterOperand (which is used most in the .td file) has the short,
> obvious name, and where the RegisterClass had "Bit" added to it.
> This gave C++ names like "GR32BitRegClass", which although a bit more
> verbose than I'd have liked did at least make some kind of sense.
>
> The problem is that I now want to add more classes where "BitRegClass"
> wouldn't make sense.  What I'd like to do instead (and wanted originally
> really) was for the RegisterClass to have the same name in the TableGen
> and C++ code, without "RegClass" being automatically added to one to get
> the other.
>
> The second patch below does this by adding an optional Name field to the
> RegisterClass.  The old X+"RegClass" scheme is still used when the
> name isn't set.  The third patch makes use of this in the SystemZ port.
>
> One snag is that although the register class is X+"RegClass" and the
> enumeration id is X+"RegClassID", the disassembler decode routines
> use X+"RegisterClass".  I could have worked around that by only
> changing the decode name when the Name field is set, but it seemed
> better to be consistent.  So the first patch makes the decode routines
> use X+"RegClass" too.
>
> I realise this probably seems like a lot of churn, but does it look OK?
>
> Thanks,
> Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename-decode.diff
Type: text/x-patch
Size: 127272 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/37114f0e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-name-field.diff
Type: text/x-patch
Size: 11853 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/37114f0e/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systemz-reg-class-names.diff
Type: text/x-patch
Size: 23692 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/37114f0e/attachment-0002.bin>