Enhance tblgen's declarative assembly format to allow attr-dict in
custom directives.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/docs/OpDefinitions.md | ||
---|---|---|
752–753 | This section needs an update. | |
783–784 | This section needs an update. | |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
1483 | Can we instead change this such that:
? |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 |
You mean regardless of the custom directive parameters or just in the attr-dict case? The former is a breaking change. I think you mean the former, which is what I would prefer as well. How much code would it break? |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 | Regardless, i.e. I think we should do both of those things.
Not much given the relative recency of custom directives. That being said, I prefer strongly to not use this as a metric for doing something. I prefer that we do the right thing regardless of whether we have to refactor existing code or not. |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 | I agree. How would we notify users? Do we even have to for breakage this small? |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 | For really small things like this I usually don't notify users. If you do need to notify in the future, I usually just drop a message in discourse letting people know something big is going to happen and give them a timeline to switch(assuming it's a staged change). |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 |
You mean to the parser, right? Presumably the printer wouldn't be modifying anything. |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
---|---|---|
1483 | I meant the printer here. The "mutable" name is a little weird, but it prevents the need to construct a DictionaryAttr if there aren't any attributes. Though an operation without attributes that implements a custom directive is probably pretty rare, so using DictionaryAttr for the printer is probably fine. |
Please add a comment to the description detailing the fact that the print function of custom directives pass the operation as well.
mlir/docs/OpDefinitions.md | ||
---|---|---|
789 | You shouldn't pass references to operations here, they are value-typed(i.e. just smart pointers). | |
811 | This wouldn't be a NamedAttrList, I would expect MutableDictionaryAttr here. NamedAttrList is expensive to construct, whereas MutableDictionaryAttr is free. | |
mlir/tools/mlir-tblgen/OpFormatGen.cpp | ||
1484 | This should be getMutableAttrDict |
mlir/docs/OpDefinitions.md | ||
---|---|---|
811 | Should it be MutableDictionaryAttr or a reference to it? getMutableAttrDict() returns a reference to the internal attribute dictionary and I don't want to give the impression that one should be mutating the object in the printer. Should it be a const reference? |
mlir/docs/OpDefinitions.md | ||
---|---|---|
811 | const MutableDictionaryAttr & SGTM |
mlir/test/lib/Dialect/Test/TestOps.td | ||
---|---|---|
1647 | There is no test actually exercising this op? |
mlir/test/lib/Dialect/Test/TestOps.td | ||
---|---|---|
1647 | It would appear not. At least not as part of this patch. I think I would have thought that if the generated file compiled, that'd be good enough. |
This section needs an update.