Support custom immediate sizes

[PhilippvK]

Currently, we only allow immediate bit widths, which are already supported by LLVM + uimm12, which needs a hardcoded patch file.

Tasks:

• Define the list of supported imm field types (per LLVM version)
• Throw an error if a non-supported immediate width is detected
• Collect all used immediate withs (per-instruction, per-set, per-model, global)
• Generate patches for custom immediates
• Add example instructions using custom imm width
• Add example instructions using multiple immediate fields
• Optional: Automatically infer the existing immediate types from the LLVM codebase
• Handle _lsb0, _lsb00,... immediate operand suffixes
• Support more complex immediate types such as uimmlog2xlennonzero

One alternative would be to introduce a new custom field type for every immediate to not conflict with the existing ones. Example: seal5_uimm5 instead of just uimm5

Challenge: It will be difficult to combine the information about the required imm types over multiple modes which is required to avoid duplicates.

[PhilippvK]

With some grepping, I came up with a list of the simm*/uimm* types which are supported in LLVM 18/19/20 respectively.

LLVM 18:

def uimm1
def uimm1
def uimm10_lsb00nonzero
def uimm2
def uimm2
def uimm20
def uimm20_auipc
def uimm20_auipc
def uimm20_lui
def uimm20_lui
def uimm2_3
def uimm2_3_XFORM
def uimm2_4
def uimm2_4_XFORM
def uimm2_lsb0
def uimm2_opcode
def uimm3
def uimm3
def uimm4
def uimm4
def uimm5
def uimm5
def uimm6
def uimm6
def uimm6gt32
def uimm6gt32
def uimm7
def uimm7
def uimm7_lsb00
def uimm7_opcode
def uimm7_opcode
def uimm8
def uimm8
def uimm8ge32
def uimm8_lsb00
def uimm8_lsb000
def uimm9_lsb000
def uimmlog2xlen
def uimmlog2xlen
def uimmlog2xlennonzero
def simm10_lsb0000nonzero
def simm12
def simm12
def simm12i32
def simm12_lsb0
def simm12_lsb00000
def simm12Minus1Nonzero
def simm12Minus1NonzeroNonNeg1
def simm12_no6
def simm12_no6
def simm12Plus1
def simm12Plus1i32
def simm13_lsb0
def simm13_lsb0
def simm21_lsb0_jal
def simm21_lsb0_jal
def simm5
def simm5_plus1
def simm5_plus1_nonzero
def simm5shl2
def simm6
def simm6nonzero
def simm9_lsb0

LLVM 19:

def uimm1
def uimm10_lsb00nonzero
def uimm16
def uimm2
def uimm20
def uimm20_auipc
def uimm20_lui
def uimm2_3
def uimm2_3_XFORM
def uimm2_4
def uimm2_4_XFORM
def uimm2_lsb0
def uimm2_opcode
def uimm3
def uimm32
def uimm4
def uimm4_with_predicate
def uimm5
def uimm5_lsb0
def uimm5_with_predicate
def uimm6
def uimm6gt32
def uimm6_lsb0
def uimm7
def uimm7_lsb00
def uimm7_opcode
def uimm8
def uimm8ge32
def uimm8_lsb00
def uimm8_lsb000
def uimm9_lsb000
def uimmlog2xlen
def uimmlog2xlennonzero
def simm10_lsb0000nonzero
def simm12
def simm12i32
def simm12_lsb0
def simm12_lsb00000
def simm12Minus1Nonzero
def simm12Minus1NonzeroNonNeg1
def simm12_no6
def simm12Plus1
def simm12Plus1i32
def simm13_lsb0
def simm21_lsb0_jal
def simm5
def simm5_plus1
def simm5_plus1_nonzero
def simm5shl2
def simm6
def simm6nonzero
def simm9_lsb0

LLVM 20:

def uimm1
def uimm10
def uimm10_lsb00nonzero
def uimm11
def uimm16
def uimm2
def uimm20
def uimm20_auipc
def uimm20_lui
def uimm2_3
def uimm2_3_XFORM
def uimm2_4
def uimm2_4_XFORM
def uimm2_lsb0
def uimm2_opcode
def uimm3
def uimm32
def uimm4
def uimm48
def uimm5
def uimm5gt3
def uimm5i32
def uimm5_lsb0
def uimm5nonzero
def uimm6
def uimm64
def uimm6gt32
def uimm6_lsb0
def uimm7
def uimm7_lsb00
def uimm7_lsb000
def uimm7_opcode
def uimm8
def uimm8ge32
def uimm8_lsb00
def uimm8_lsb000
def uimm9_lsb000
def uimmlog2xlen
def uimmlog2xlennonzero
def simm10_lsb0000nonzero
def simm12
def simm12_lsb0
def simm12_lsb00000
def simm12Minus1Nonzero
def simm12Minus1NonzeroNonNeg1
def simm12_no6
def simm12_plus1
def simm12Plus1
def simm12Plus1i32
def simm13_lsb0
def simm21_lsb0_jal
def simm26
def simm5
def simm5_plus1
def simm5_plus1_nonzero
def simm5shl2
def simm6
def simm6nonzero
def simm9_lsb0

[PhilippvK]

I hope we can also take care of more special imm types such as simm12_lsb0 and uimm7_lsb00 (at least the trivial ones)

[PhilippvK]

My plan is to introduce seal5_settings.llvm.state.supported_imm_types which can be provided either by the user or populated automatically by Seal5.

Each set can store its own used imm types in seal5_settings.models.{model_name}.extensions.{set_name}.required_imm_types and a global pass can combine them (and drop duplicates) to finally generate the required patches.

I was thinking about adding a LLVMImmType dataclass to the settings, but decided to stick with strings for now. I do not think that we will need to deal with very complex types such as simm12Minus1NonzeroNonNeg1 anyways, to i hope we can infer the sign and constraints (i.e. lsb == 0) from the name.

[PhilippvK]

There is one more annoying problem... Not all imm field types are defined in the same file for LLVM. simm5 for isntance is defined in RISCVInstrInfoV.td instead of RISCVInstrInfo.td. Should we add our patches for new imm types to RISCVInstrInfo.td or seal5/imm_types.td?

[PhilippvK]

I also realized that some enum entries such as OPERAND_UIMM12 already exist in RISCVBaseInfo.h but there is no uimm12 field type.

The same holds for the isUInt12,... utils.

If that turns out to be an issue we will need to track supported_riscv_operands, supported_field_types, support_asm_funcs...

A compromise might be defining our own RISCVUImmOp and generating SEAL5_OPERAND_UIMM12 instead.