- Provide default value for ArrayRef<NamedAttribute> attributes parameter of the collective params build method.
- Change the genSeparateArgParamBuilder function to not generate build methods that may be ambiguous with the new collective params build method.
- This change should help eliminate passing empty NamedAttribue ArrayRef when the collective params build method is used
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I looked into extending the op-decl.td unit test, but the way the tests are currently setup we have a mix of mlir and td tests under test/mlir-tblgen, so its not possible to observe the unit test failure because mlir-opt fails to build with a broken mlir-tblgen. In an attempt to make the mlir-tblgen dependent tests to be run independently from mlit-opt dependent tests, I have put up another review (https://reviews.llvm.org/D83528) to split the tests under mlir-tblgen into two directories. I'll update the this one with a unit tests once that change goes in and I can test (easily) that my unit tests fails if I disable the suppression of generating the ambiguous build methods
So the goal of this change is to avoid needing to specify empty array of attributes if there are none for the collective case? (We have default attributes and so the description was a bit ambiguous wrt that)
Yes, but these unit tests don't test if mlir-tblgen is broken, they test if it produces expected results.
Now if mlir-tblgen is incorrect to the point where mlir-tblgen produces invalid C++ code so that mlir-opt can't compile, then yes we won't see the unit tests mlir-tblgen running. That's a pain and one affecting folks working on mlir-tblgen. Today they could run the test commands manually or just disable also building mlir-opt in the test suite and run the tests, buts it not automatic.
So if we look to improve that, what would the goal be to make it easier for folks developing mlir-tblgen? Or to test valid C++ code is generated? E.g., we don't test the latter except with mlir-opt today and so is the plan to address that? That is also a different discussion and we could discuss on the splitting change to
So the goal of this change is to avoid needing to specify empty array of attributes if there are none for the collective case? (We have default attributes and so the description was a bit ambiguous wrt that)
Yes, that's the goal. Currently I see several uses of this build/create method where we are passing empty array of attributes and the goal is to eliminate that from the code. This has nothing to do with default *values* attributes, I think I saw another bug regarding them, bit this change is not attempting to fix that. I can reword this to "Change collective params build method to have an empty default value for attributes".
As for the unit test issue, yes, lets have that as a separate discussion. For now, am maintaining the status quo there and extending the existing test with addition tests. If/when we migrate the mlir-tblgen unit test to the C++ unittest, I expect these will migrate with that.
Nice, thanks for expanding the documentation there
mlir/test/mlir-tblgen/op-decl.td | ||
---|---|---|
186 | suppression ? Could you expand to say why? | |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
964 | Missing ) | |
970 | Why is a single variadic result required? I think you might mean at most one variadic result | |
1221 | s/if/as/ ? (if here makes me think there are cases where we get here where this is not true) |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
1221 | nit: Please move the comment out of the else body, or add braces. This makes the body "non-trivial". |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
1221 | nit: When adding braces to an else/if, add the braces to all of the if/elses in the chain. |
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp | ||
---|---|---|
970 | I do mean a single variadic result. The build() method we are trying to suppress is one with a single ArrayReg<Type> argument for result types and a single ArrayRef<Value> for operands, and no other parameters after that. That condition for the first one is either a a collective paramKind for result type, or a separate with a single variadic result. If there are no results, I am assuming the separate paramKind will not generate any ArrayRef<Type> argument for a non-result (buildParamList case TypeParamKind::Separate iterates over numResults, which will be 0). I guess I could make the comment clearer by segregating these 2 criteria and describing the conditions for these 2 differently (conditions for generating a single ArrrayRef<Type> and condition for generating a single ArrayRef<Value> for operands). |
suppression ?
Could you expand to say why?