[llvm-dev] TableGen: spring cleaning, new features for "functional programming"
Nicolai Hähnle via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 19 11:26:56 PST 2018
Hi all,
While working on some features for the AMDGPU backend -- specifically,
explicit address components for image intrinsics, which involves
generating both
(a) a lot of intrinsics with different but somewhat regular parameter
types, and
(b) the patterns to select instructions for those intrinsics
-- I got fed up with a lot of the TableGen bugs and limitations and set
out to fix things.
I now have an already rather long list of ~30 patches which do a bunch
of things in lib/TableGen/ such as:
- better and earlier error messages
- cleanup type checking
- cleanup variable resolving
- cleanup record instantiation
- late generation of anonymous records that appear in expressions
- cleanup !foreach
- add !foldl
- add !isa<type>(...) and make !cast more useful
- add !dag builtin to generate DAG nodes from lists
- some other minor new built-ins like !size, !le, !lt, !ge, !gt
- add a defset mechanism for collecting records which can then later be
looped over in a foreach statement
- make foreach statements in multiclass work
- probably more...
An earlier version of the patches is here if you already want to take a
look: https://cgit.freedesktop.org/~nh/llvm/log/?h=mimg
My plan is to clean those up over the next days and weeks and submit
them to Phabricator.
With the exception of !foreach, which doesn't actually seem to be used,
all the changes should be backward compatible. In fact, most of the
larger changes are simply refactoring TableGen in a way that makes
things work that look like they should already work but don't.
I would appreciate feedback and help in reviewing the patches when they
arrive!
Thanks,
Nicolai
P.S.: I'm going to document some of my findings and changes on my blog,
the first entry is here:
https://nhaehnle.blogspot.de/2018/02/tablegen-1-what-has-tablegen-ever-done.html
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
More information about the llvm-dev
mailing list