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

[Krzysztof Parzyszek via llvm-dev]

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.


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

> def Is64Bit : Predicate<"Subtarget->is64Bit()">;
> def RCInfo64 : RCInfo<Is64Bit> {
>   let RegTypes = [i64, v2i32, v4i16, v8i8];
>   .....
> }
>
> class MyRegisterClass : RegisterClass<...> {
>   let RCInfos = [RCInfo32, RCInfo64]
> }

With the RCInfo data, the new register class definition would be 
something like

class MyRegisterClass : RegisterClass<...> {
   let RCInfos = HwModeSelect<[Is32Bit,  Is64Bit,  Is128Bit],
                              [RCInfo32, RCInfo64, RCInfo128]>;
}

In either case, aggregating the info in a RCInfo class would require 
additional changes in TableGen so that it picks up the 
size/alignment/type data from the RCInfos list, instead of from 
individual members. This is doable and there are no technical barriers 
to do it. It may actually be a good idea, since it would isolate the 
part of the register class definition into a single object.

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.

-Krzysztof