This is an archive of the discontinued LLVM Phabricator instance.

[TableGen] Add !getdagargs and !getdagnames
AbandonedPublic

Authored by hliao on May 25 2023, 8:40 AM.

Details

Summary
  • This patch proposes to add !getdagargs and !getdagnames bang operators as the inverse operation of !dag. They allow us to examine arguments of a specified dag.

Diff Detail

Event Timeline

hliao created this revision.May 25 2023, 8:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 8:40 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
hliao requested review of this revision.May 25 2023, 8:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 8:40 AM
simon_tatham added inline comments.May 25 2023, 9:06 AM
llvm/docs/TableGen/ProgRef.rst
1718–1720

That seems quite restrictive – it means this system can't be used at all in any context where the arguments to a dag are intentionally heterogeneous.

A couple of possible alternatives:

  1. Make !getdagargs<T>(dag) return ? without error for each argument whose type isn't T or a subtype.
  1. Instead of an operator to fetch all the arguments at once, have an operator to fetch just one at a time, say !getdagarg<T>(dag, index). Then if I have a dag operator that always expects a Foo and a Bar, I can call !getdagarg<Foo>(d, 0) and !getdagarg<Bar>(d, 1).

With option 2, if there were also an operator to return the number of arguments, then you could still get a list of all of them using !foreach.

I agree with Simon's suggestions.

I also suggest that the tests include some dags that are more complex, with nested dags as operands. And, given Simon's suggestions, some non-homogeneous dags.

hliao added inline comments.May 25 2023, 6:52 PM
llvm/docs/TableGen/ProgRef.rst
1718–1720

Yes, for completeness, !getdagarg(arg, name) and !getdagarg(arg, idx) (without casting to T) are the 2nd part I was preparing together with !getdagname(arg, idx).
I will update the patch to allow arguments with non-common type returned as ?.

hliao updated this revision to Diff 525925.May 25 2023, 8:04 PM

Now return ? if an argument has unmatching type. Tests are updated.

hliao updated this revision to Diff 526197.May 26 2023, 2:23 PM

Allow convertible types and update tests

hliao added a comment.May 26 2023, 6:25 PM

The alternative approach is uploaded @ https://reviews.llvm.org/D151602

hliao updated this revision to Diff 526230.May 26 2023, 6:26 PM

Fix clang-format issue

hliao updated this revision to Diff 526456.May 29 2023, 10:27 AM

Rebase and ping for review. The alternative approach is posted @ https://reviews.llvm.org/D151602

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

llvm/docs/TableGen/ProgRef.rst
1718–1720

You might want to rephrase this sentence. It can be interpreted as "we return ? as the overall result of the operation if any of the arguments cannot be cast to <type>", which is not what you do in your tests, you return ? only for the argument that cannot be cast to type.

Having said that, I'd prefer to avoid this behaviour, and opt for an error, for 2 reasons:

  1. If we require the user to specify <type>, we can assume that the user to know what they are doing. Prompting an error would be informative, and could prevent sessions of debugging yablegen failures that might happen quite far away from where the real issue is.
  2. At the end of the day, if we decide to return ? for arguments that cannot be cast, we could avoid to require the type argument in the operator, and just get it from the first element of the list, or programmatically find a common ancestor in the types of the arguments.

In my version I opted for the error: https://reviews.llvm.org/differential/changeset/?ref=4198690

Of course, the whole discussion around this fails if you have uses cases in which you "need" to return ? (I didn't have those...)

1722

Why do you need to specify <type> in here? Isn't it obvious a list of strings will be returned? Or do we get issues with those arguments whose name is unset and need to be returned as ?.

llvm/lib/TableGen/TGLexer.h
38

Do you need to clang-format these file? I preferred the original formatting. Please consider reverting back to the original format, just add the two new enums for the operators you have added in the list for bang operators.

llvm/test/TableGen/getsetop.td
72

Would it make sense to have these tests in a separate file, specifically for the two new operators?

hliao added a comment.May 30 2023, 1:27 PM

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

I proposed another change introducing !getdagarg and !getdagname to access individual arguments instead of a list of them. Personally, I thought that should be more convenient.

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

I proposed another change introducing !getdagarg and !getdagname to access individual arguments instead of a list of them. Personally, I thought that should be more convenient.

Does it mean that you want to abandon this change?

hliao added a comment.May 31 2023, 8:35 AM

Hey @hliao - thank you for this patch. Apparently we had a similar idea D151702 :)

I just have a couple of comments.

Thanks!

Francesco

I proposed another change introducing !getdagarg and !getdagname to access individual arguments instead of a list of them. Personally, I thought that should be more convenient.

Does it mean that you want to abandon this change?

yeah, !getdagargs could be built upon !getdagarg. For example, given a dag input, !getdagargs<T>(input) could be implemented as

!foreach(i, !range(!size(input)), !getdagarg<T>(input, i)

Even though a little bit verbose, getdagarg allows us to examine an individual argument without fetching all arguments. In addition, we also allow using the argument name in addition to the argument index. That allows us to check arguments based on their names conveniently.

hliao abandoned this revision.May 31 2023, 8:36 AM

As getdagargs and getdagnames could be implemented upon getdagarg and getdagname, this patch is redundant.