[llvm-dev] Auto-generating MachineValueTypes

[Fraser Cormack via llvm-dev]

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