This is an archive of the discontinued LLVM Phabricator instance.

[TableGen] Add a permissive version of !con.
AbandonedPublic

Authored by simon_tatham on Dec 6 2019, 6:19 AM.

Details

Reviewers
nhaehnle
hfinkel
Summary

It can be inconvenient that !con will only let you concatenate dag
nodes if their operators match, because sometimes you need to combine
a dag fragment you've already got (e.g. passed in as a template
argument) with an operator you're making up on the spot (e.g. by
instantiating some other templated class, or constructing a string and
casting it to a record).

This patch introduces !conp, which works just like !con except
that it uses the operator from its first argument, and doesn't care
what the operators of subsequent arguments are.

!conp provides an alternative approach to programmatic dag node
construction, without the limitation of !dag that all the arguments
have to be of the same type: now you can give your sublists of dag
arguments in dag form, so they can take any types valid in a dag at
all, even if they're all different.

Another simple use of !conp is to replace just the operator of an
existing dag: !conp((foo), (bar x, y, z)) returns (foo x, y, z).

Event Timeline

simon_tatham created this revision.Dec 6 2019, 6:19 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 6 2019, 6:19 AM

(The name !conp was just the first name that sprang to my fingers when I had to call it something. I don't at all mind changing the name to something completely different, but I'd prefer it if it was still something reasonably short :-)

hfinkel added a subscriber: hfinkel.Dec 6 2019, 6:38 AM

Did you consider introducing something to change the dag operator instead of this? I think it might be cleaner to have some kind of thing which changes the dag operator, and after that, if you wish to !con them, everything works as expected.

Yes, I did. I prefer this way, because it comes out considerably shorter in the use case I had in mind. Compare these two (inside a templated class with a parameter dag extraArgs which might be, say, (args 3, 4)):

dag d = !conp((MyRealOperator<...> a, b), extraArgs);
dag d = !setop(MyRealOperator<...>, !con((args a, b), extraArgs));

But I can implement !setop if you prefer. (And while I'm at it, perhaps !getop too.)

Another even sillier thought I considered was to change !con itself so that it can accept an unset ? value as a dag operator, and only insists that the operands that have defined operators should all agree with each other. That would have been even terser!

But you can't write a dag with an unset operator node easily: (? 1, 2, 3) isn't valid input syntax for a dag, even though there are things you can do that will cause -print-records to produce it as output. Also, it's surely setting a bad precedent...

But I can implement !setop if you prefer. (And while I'm at it, perhaps !getop too.)

Personally, I'd prefer this. I realize that the code is longer, but I think it will be much clearer what's going on.

I don't feel particularly strongly either way, but it seems to me that allowing an unset operator could perhaps be the most elegant solution after all. I'm lacking the context of your particular use case, but it seems to me you're attempting to piece together DAG fragments in a generic way where the operator simply isn't known yet by some of the pieces of TableGen you're writing, and using an unset operator could be a more natural way of expressing that than coming up with some artificial operator that is simply thrown away later.

I think !getop and !setop are likely to be useful whether or not I end up using them for this particular use case, so I've written them anyway, and submitted them as the separate patch D71191.

using an unset operator could be a more natural way of expressing that than coming up with some artificial operator that is simply thrown away later.

Artificial operators are quite common already in the Tablegen idiom, though, to get round the fact that all dags have to have an operator. For example, the inputs and outputs of MC instructions have the form of dags so that each one can have a type and a name, and then they have to have the dummy operators ins and outs because something has to go in the operator slot.

But if you're not opposed to making an unset dag operator legal, then I'll at least look into it!

And D71195 is the change to allow dag operators to be ?. Now I have three potential ways to do the thing I wanted :-)

simon_tatham abandoned this revision.Dec 11 2019, 4:26 AM

D71191 and D71195 are both now committed (thanks!), so I have a choice of two ways to achieve my original objective, and no further need for this third one.