[PATCH] D23561: [RISCV 4/10] Add basic RISCV{InstrFormats, InstrInfo, RegisterInfo, }.td

[Alex Bradbury via llvm-commits]

asb added a comment.

Apologies for the slight delay, organising last week's LLVM Cauldron <http://llvm.org/devmtg/2016-09/> and other activities in my life had limited my time.

As discussed here, we really want to have two separate register classes for RV32 and RV64 and separate instruction definitions to match this. In RISC-V, an RV32 add and an RV64 add (and indeed, a future RV128 add) all use the same encoding. There seem to be a number of possible approaches to handling this:

- As done by other backends such as Sparc would, ust define every instruction twice.
- Make classes in RISCVInstrInfo like `ALU_rr` multiclasses that define both 32-bit and 64-bit versions of instructions.
- You could also imagine extending TableGen with some sort of AST macro support or a new tablegen option that would handle substituting the register class for each defined instruction
- A foreach at the top of RISCVInstrInfo that iterates over each register width (for now, 32 and 64-bit). Each def would be to be written like `def ADD#x` and some `!cast` or `!if` magic would be needed to get the appropriate RegisterClass based on the register width.
- Move all class definitions to the top of RISCVInstrInfo and make each `ALU_rr` etch take a RegisterClass parameter. Then define a multiclass used to parametrise all instruction definitions.

I have trialled the last option from the list above. You can see a version of RISCVInstrInfo.td (based on the complete patchset) that implements this option at paste https://reviews.llvm.org/P7637. For those subscribing to this review - I'd really appreciate your comment on if you feel this is the best way to go about it (particularly TableGen wizards like @t.p.northover). Given the current patchset aims to focus on MC, I propose actually making this change in a later patch when RV32/RV64 codegen is introduced.


https://reviews.llvm.org/D23561