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

[Alex Bradbury via llvm-dev]

On 4 October 2016 at 19:50, Krzysztof Parzyszek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> If there are no objections, I'd like to start working on this soon...
>
> For the AMDGPU target this implies that RC->getSize will no longer be
> available in the MC layer.

Another advantage of this work that hasn't been mentioned yet is it
will reduce the number of uses of isCodeGenOnly. The comment in
Target.td indicates the long-term plan is to remove the distinction
between isPseudo and isCodeGenOnly.

A closely related to variable-sized register classes is the case where
you have multiple registers with the same AsmName. This crops up in
the same kind of cases where you have multiple instructions with the
same encoding. Without a workaround, an assert is tripped in
llvm-tblgen when trying to produce a StringSwitch for
MatchRegisterName. The solution in Mips, PPC and others seems to be
involve the generation of MatchRegisterName. What has been discussed
so far with regards to HwMode and variable-size register classes
points to a solution, but I don't think it's quite enough. Options
include:

1. Only have one set of register definitions, and have the variable
sized register class determine the bit width. The problem is there are
often some instructions where I think you need to have registers
modelled as subregisters. e.g. SLLW, ADDW etc in 64-bit RISC-V. These
operate on 32-bit values and write the results sign-extended to the
target 64-bit register.

2. Define both the 64-bit registers and the 32-bit subregisters, but
make MatchRegisterName's behaviour change based on the HwMode. This
works around the fact there are multiple registers with the same
AsmName. Although I doubt this would actually cause problems, this
still isn't quite right. For an `SLLIW x1, x2, 5` I think the correct
interpretation would have x1 as a 64-bit target register and x2 as the
32-bit subregister that happens to have the same AsmName as the 64-bit
x2 register.

Have you thought about how the HwMode/variable-sized register class
proposal might interact with register AsmNames at all?

This old patch that never landed
<http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20141201/246835.html>
is also I think related. Backends like Mips and PPC end up defining
RegisterOperand with a ParserMatchClass (in the Mips case, this
specified the 'parseAnyRegister' ParserMethod. Adding a
ParserMatchClass field to RegisterClass would be a minor
simplification.

Best,

Alex