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

[Krzysztof Parzyszek via llvm-dev]

On 9/24/2016 10:50 AM, Alex Bradbury wrote:
> 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.

The mode/select approach is general---you can make just about anything 
be specific to a particular hw mode. Changing TableGen to treat RCInfos 
specially is going to accomplish only that, nothing more.


>> > 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?

Type inference in TableGen relies on knowing the exact set of types 
allowed for a particular expression. This is exactly why this HwMode is 
needed: if a register class MyRegClass can hold i32 in one mode and i64 
in another mode, TableGen must know that the list of allowable types is 
either [i32] or [i64], and it cannot be [i32, i64]. Tagging each type 
with a mode would instead make it look like [i32:Mode32, i64:Mode64], 
which is equivalent to saying "Mode32 -> [i32], Mode64 -> [i64]", or 
"[Mode32, Mode64], [i32, i64]" with the understanding that corresponding 
list elements are to be taken together.

This is really only needed for selection patterns. If you just want to 
be able to define instructions (via def xxx : Instruction<...>), then 
the mode/select is not necessary.


> 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)?

 From the point of view of instruction descriptors nothing would really 
change. A ShortIntegerRegisterClass would still be different from 
LongIntegerRegisterClass. The difference would be that when you query 
them from TargetRegisterInfo about spill slot sizes, etc, you could get 
different answers for different subtargets.

-Krzysztof