[llvm-dev] RFC: Implement variable-sized register classes (original) (raw)

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 8 12:52:29 PDT 2016

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

More information about the llvm-dev mailing list