[llvm-dev] RFC: Implement variable-sized register classes

[Alex Bradbury via llvm-dev]

On 24 September 2016 at 14:12, Krzysztof Parzyszek
<kparzysz at codeaurora.org> wrote:
> On 9/24/2016 7:20 AM, Alex Bradbury wrote:
>>
>> My concern is that all of the above adds yet more complexity to what
>> is already (in my view) a fairly difficult part of LLVM to understand.
>> The definition of MyRegisterClass is not so bad though, and perhaps it
>> doesn't matter how it works under the hood to the average backend
>> writer.
>
>
> I agree with the complexity, but I would hope that more documentation,
> examples and explanations would clarify it.

Agreed.

>
>> What if RegisterClass contained a `list<RCInfo>`. Each RCInfo contains
>> RegTypes, RegSize, SpillSize, and SpillAlignment as well as a
>> Predicate the determines whether this individual RCInfo is the one
>> that should apply. To my taste this seems easier to understand than
>> the {Int,ValueType,ValueTypeList}Select mechanism.
>
>
> The "select" mechanism was intended to be extendable to be able to select
> any object of any type based on the predefined mode. It is entirely possible
> to use it in a similar way to what you describe below.
<snip>
>
> class MyRegisterClass : RegisterClass<...> {
>   let RCInfos = HwModeSelect<[Is32Bit,  Is64Bit,  Is128Bit],
>                              [RCInfo32, RCInfo64, RCInfo128]>;
> }

I think what I'm really suggesting is that rather than adding this
special HwModeSelect mechanism where both HwMode and HwModeSelect are
treated specially by TableGen, we instead make the RegisterClass
itself (specifically its RCInfos field) be treated specially by
TableGen.

> On a side note---there is a distinction between "mode" and "predicate":
> modes are distinguished by name, which is necessary because they need to be
> distinguishable during the run-time of TableGen. Predicates are evaluated
> after TableGen is done, during the run-time of the code generated by it. I
> didn't want to differentiate predicates based on their names, since that
> would go against expectations of how predicates have behaved so far.

I think I don't fully understand the design limitations here. How
exactly are HwModes used at tblgen execution time? As I understand it,
the chosen HwMode couldn't be selected at tblgen time (after all,
that's a subtarget property that will be known only when the compiler
is invoked) but from what you say, there's a point where different
HwModes must be differentiated?

Also how will the generated output be different? e.g. right now in
MIPS for OR in MipsGenInstrInfo we have:
  { 1754, 3,  1,  4,  232,
0|(1ULL<<MCID::Commutable)|(1ULL<<MCID::Rematerializable), 0x1ULL,
nullptr, nullptr, OperandInfo25, -1 ,nullptr },  // Inst #1754 = OR
  { 1757, 3,  1,  4,  232,
0|(1ULL<<MCID::Commutable)|(1ULL<<MCID::Rematerializable), 0x1ULL,
nullptr, nullptr, OperandInfo43, -1 ,nullptr },  // Inst #1757 = OR64

Where OperandInfo25 and OperandInfo43 obviously differ in terms of
register class. As I understand it, with this proposal only one entry
would be generated and OperandInfoNN would be defined in terms of our
variable-sized register class. But for MipsGenDAGISel.inc, would
multiple patterns be implicitly generated (one for each HwMode)?

Thanks,

Alex