<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 19, 2018 at 11:26 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
While working on some features for the AMDGPU backend -- specifically,<br>
explicit address components for image intrinsics, which involves<br>
generating both<br>
<br>
(a) a lot of intrinsics with different but somewhat regular parameter<br>
types, and<br>
<br>
(b) the patterns to select instructions for those intrinsics<br>
<br>
-- I got fed up with a lot of the TableGen bugs and limitations and set<br>
out to fix things.<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​It must be the season. :-) I've been tactically cleaning up the most annoying (for me) tablegen issues I've ran into, but your patch set makes things way more interesting. ​</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I now have an already rather long list of ~30 patches which do a bunch<br>
of things in lib/TableGen/ such as:<br>
<br>
- better and earlier error messages<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">​+100. </div><div class="gmail_default" style="font-family:verdana,sans-serif">​</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- cleanup type checking<br>
- cleanup variable resolving<br>
- cleanup record instantiation<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​That can mean whole lot of different things. ​Do you have an overarching plan how tablegen is supposed to do all of the above in a consistent manner? Just making it different may not improve things much.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- late generation of anonymous records that appear in expressions<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​That would help, somewhat, though the biggest problem (IMO) with the anonymous records is that when they are instantiated using multiclass template parameters, the inner records are not folded because the values are not known yet and they may never be known because instantiated anonymous record has no access to template arguments that may be used by its fields. If you moved instantiation of anonymous records to the point where the instances of the class/multiclass that uses them are generated, that would help a lot.​</div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- cleanup !foreach<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​+1 for having scoped temporary variable. ATM tablegen can use a class field for that, but using it in the global scope still needs a record for it. Things also go wrong when one accidentally uses a record/field with a known value.​ </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- add !foldl<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- add !isa<type>(...) and make !cast more useful<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​Nice.​</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- add !dag builtin to generate DAG nodes from lists<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​Yes, please! Constructing dags using !foreach and !con()​ is a pain.</div></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- some other minor new built-ins like !size, !le, !lt, !ge, !gt<br>
- add a defset mechanism for collecting records which can then later be<br>
looped over in a foreach statement<br>
- make foreach statements in multiclass work<br>
- probably more...<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​I'll list few things that I have on my list of tablegen annoyances to fix:​</div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">- ​!subst() needs some minor tweaks when it's applied to dag from !foreach -- it wants specific types, but I sometimes want to replace a dag argument (a record) with another dag​.</div><div class="gmail_default" style="font-family:verdana,sans-serif">​- I want some sort of !macro() operator that will never be folded by itself, but will instead literally substitute its value when it's used, so it will have access to the multiclass template arguments, class fields, etc.​ We're currently using anonymous records for similar purposes, but those are instantiated at the wrong time, so it's often impossible to use them as sort of 'subroutines'. Your late generation change you've mentioned above may help, but I'm not sure if that's the use pattern you had in mind.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
An earlier version of the patches is here if you already want to take a<br>
look: <a href="https://cgit.freedesktop.org/~nh/llvm/log/?h=mimg" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/~nh/llvm/log/?h=mimg</a><br>
<br>
My plan is to clean those up over the next days and weeks and submit<br>
them to Phabricator.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​I'd be happy to help reviewing them.​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
With the exception of !foreach, which doesn't actually seem to be used,<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">I do have few outstanding changes for NVPTX where I rely on !foreach, but I think it should not be too hard to adapt them.​</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
all the changes should be backward compatible. In fact, most of the<br>
larger changes are simply refactoring TableGen in a way that makes<br>
things work that look like they should already work but don't.<br>
<br>
I would appreciate feedback and help in reviewing the patches when they<br>
arrive!<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">​Count me in. And thank you for doing this work!</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">--Artem​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Nicolai<br>
<br>
P.S.: I'm going to document some of my findings and changes on my blog,<br>
the first entry is here:<br>
<a href="https://nhaehnle.blogspot.de/2018/02/tablegen-1-what-has-tablegen-ever-done.html" rel="noreferrer" target="_blank">https://nhaehnle.blogspot.de/2018/02/tablegen-1-what-has-tablegen-ever-done.html</a><br>
<br>
--<br>
Lerne, wie die Welt wirklich ist,<br>
Aber vergiss niemals, wie sie sein sollte.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--Artem Belevich</div></div></div>