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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 24 09:56:39 PDT 2016


On 24 September 2016 at 17:25, Krzysztof Parzyszek
<kparzysz at codeaurora.org> wrote:
> 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.

I agree it's definitely more general, I'm just wondering whether there
are really additional areas you'd want to use mode/select. Though on
balance I think I agree - treating RCInfo specially wouldn't reduce
the TableGen changes all that much so probably isn't worth the loss in
generality.

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

Thank you, that makes things much clearer in my mind.

I feel the duplication that will be removed by variable-sized register
classes is very valuable, and I'm certainly stumped for ideas on how
to achieve the same goal in a simpler way. I'd need to try out the
multiclass approach on an InstrInfo.td with instruction patterns for a
full comparison, but suspect this variable-sized register class
proposal will end up being much cleaner.

Alex


More information about the llvm-dev mailing list