[llvm-dev] Auto-generating MachineValueTypes

Fri Jun 11 06:53:01 PDT 2021

(adding llvm-dev to my previous post)

> -----Original Message-----
> From: Björn Pettersson A
> Sent: den 11 juni 2021 15:52
> To: Mikael Holmén <mikael.holmen at ericsson.com>; Fraser Cormack
> <fraser at codeplay.com>
> Subject: RE: Auto-generating MachineValueTypes
> 
> Yes, I've had the same kind of idea in the past.
> 
> Don't remember exactly what I found most complicated (maybe I was too much
> of an LLVM newbie to take on the task).
> 
> It might have been that to build tablegen one need the MachineValueType.h
> headerfile. It is include from various files in utils/TableGen. So how do
> we generate that file using tblgen if we can't build tblgen first?
> 
> Maybe your idea is to use some other file as input when building
> tblgen (removing all includes of MachineValueType.h from utils/TableGen),
> and then generate a file that can be included by MachineValueType.h for
> other non-tblgen users. Or maybe tblgen need to be built twice (first
> without other tblgen backends, then including the other tblgen backends
> that depend on MachineValueType.h).
> 
> Anyway, I totally agree that it would be awesome if this can be improved.
> 
> Regards,
> Björn
> 
> > -----Original Message-----
> > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Mikael
> Holmén
> > via llvm-dev
> > Sent: den 11 juni 2021 15:21
> > To: llvm-dev at lists.llvm.org; Fraser Cormack <fraser at codeplay.com>
> > Subject: Re: [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
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://protect2.fireeye.com/v1/url?k=eed832df-b1430b9b-eed87244-
> > 861d41abace8-102401ed78585d41&q=1&e=3de1552d-e4b6-43fb-9ae9-
> > e67f6a0a5cf2&u=https%3A%2F%2Flists.llvm.org%2Fcgi-
> > bin%2Fmailman%2Flistinfo%2Fllvm-dev