Björn Pettersson A via llvm-dev
2021-Jun-11 13:53 UTC
[llvm-dev] Auto-generating MachineValueTypes
(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