- 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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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:
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.
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). |
Rebase and ping for review. The alternative approach is posted @ https://reviews.llvm.org/D151602
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:
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? |
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.
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.
As getdagargs and getdagnames could be implemented upon getdagarg and getdagname, this patch is redundant.
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:
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.