Fraser Cormack via llvm-dev
2021-Jun-11 11:41 UTC
[llvm-dev] Auto-generating MachineValueTypes
Hi everybody, I can't be the first to consider this so I'm wondering if I've missed something obvious. Has anyone discussed or attempted auto-generating (parts of) the MachineValueType.h header? There are a couple of issues with it that could certainly be improved: 1. The enum-value data is multiply-defined in include/llvm/Support/MachineValueType.h and include/llvm/CodeGen/ValueTypes.td 2. The explicit numbering of enum values in each file makes diffs verbose due to cascading, and errors are easy to miss 3. Inconsistencies between these enum values are not guaranteed to show errors at compile time and (in my experience anyway) some bugs may only be exposed by one or two lit tests The factors above are such that we've accepted patches with new types from out-of-tree targets just to make their downstream lives easier. I myself have been on the downstream side of things before and it is a nuisance. With RISC-V, and perhaps with other variable-length vector targets, I could foresee downstream forks adding their own custom wide vector types. It'd be nice to make things simpler for that workflow too. Since we already have the MVT data in TableGen, I was wondering if it's possible to use those to auto-generate the enum values and even some of the trivial helper functions like (getVectorElementType, getSizeInBits, etc) with a new TableGen backend. My high-level goal would be to introduce the ability to add a new regular type with one line of code. Since the enum order is important to parts of the code generator, I was envisaging the type data being ordered into a list and having the enum values come out of that. The pseudo markers like FIRST_INTEGER_VALUETYPE could no doubt be inferred but could also be explicitly placed. The type data itself could build up types from scalar types to vector ones so all of the size/vector element/vector length is known and can be used to auto-generate methods: def i32 : IntegerValueType<32>; def v2i32 : VectorValueType<i32, 2>; For markers, I would imagine that it would be possible to track when we've transitioned from a scalar integer type to a scalar floating point type and add a marker. If we find another scalar integer type later in the list we can error to prevent odd ordering issues. I realise this is quite similar to the type hierarchy in include/llvm/IR/Intrinsics.td so I don't know if this idea could be used or shared with the Intrinsics' types to make them simpler. Alternatively, since I've no doubt missed some complexity (or triviality), does anyone else have any ideas that could improve this part of the code generator? Cheers, Fraser
Mikael Holmén via llvm-dev
2021-Jun-11 13:20 UTC
[llvm-dev] Auto-generating MachineValueTypes
Hi, I also don't know if there are some hidden problems with generating (parts of) MachineValueType.h but living with a downstream clone with 12 added MVTs (some really early in the enum) compared to trunk, it would simplify dealing with trunk changes to the types a lot! I don't know how many times I've manually had to deal with MachineValueType.h and ValueTypes.td due to reformatting or new types and it's a pain every time. It would be awesome if this could be simplified! /Mikael ________________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fraser Cormack via llvm-dev <llvm-dev at lists.llvm.org> Sent: Friday, June 11, 2021 1:41 PM To: llvm-dev at lists.llvm.org Subject: [llvm-dev] Auto-generating MachineValueTypes Hi everybody, I can't be the first to consider this so I'm wondering if I've missed something obvious. Has anyone discussed or attempted auto-generating (parts of) the MachineValueType.h header? There are a couple of issues with it that could certainly be improved: 1. The enum-value data is multiply-defined in include/llvm/Support/MachineValueType.h and include/llvm/CodeGen/ValueTypes.td 2. The explicit numbering of enum values in each file makes diffs verbose due to cascading, and errors are easy to miss 3. Inconsistencies between these enum values are not guaranteed to show errors at compile time and (in my experience anyway) some bugs may only be exposed by one or two lit tests The factors above are such that we've accepted patches with new types from out-of-tree targets just to make their downstream lives easier. I myself have been on the downstream side of things before and it is a nuisance. With RISC-V, and perhaps with other variable-length vector targets, I could foresee downstream forks adding their own custom wide vector types. It'd be nice to make things simpler for that workflow too. Since we already have the MVT data in TableGen, I was wondering if it's possible to use those to auto-generate the enum values and even some of the trivial helper functions like (getVectorElementType, getSizeInBits, etc) with a new TableGen backend. My high-level goal would be to introduce the ability to add a new regular type with one line of code. Since the enum order is important to parts of the code generator, I was envisaging the type data being ordered into a list and having the enum values come out of that. The pseudo markers like FIRST_INTEGER_VALUETYPE could no doubt be inferred but could also be explicitly placed. The type data itself could build up types from scalar types to vector ones so all of the size/vector element/vector length is known and can be used to auto-generate methods: def i32 : IntegerValueType<32>; def v2i32 : VectorValueType<i32, 2>; For markers, I would imagine that it would be possible to track when we've transitioned from a scalar integer type to a scalar floating point type and add a marker. If we find another scalar integer type later in the list we can error to prevent odd ordering issues. I realise this is quite similar to the type hierarchy in include/llvm/IR/Intrinsics.td so I don't know if this idea could be used or shared with the Intrinsics' types to make them simpler. Alternatively, since I've no doubt missed some complexity (or triviality), does anyone else have any ideas that could improve this part of the code generator? Cheers, Fraser _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://protect2.fireeye.com/v1/url?k=e0554a08-bfce72ea-e0550a93-86073b36ea28-ddb0e791a5eef4b9&q=1&e=8c8c773b-dfc3-4fac-9982-5bc622c74f73&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev