- This allows us to hoist trait level information for regions and sized-variadic to class level attributes (_ODS_REGIONS, _ODS_OPERAND_SEGMENTS, _ODS_RESULT_SEGMENTS).
- Eliminates some splicey python generated code in favor of a native helper for it.
- Makes it possible to implement custom, variadic builders with one line of python, without needing to manually code access to the segment attributes.
- A follow-up will actually add ODS support for generating custom Python builders that delegate to this new method.
- Also includes the start of an e2e sample for constructing linalg ops where this limitation was discovered (working progressively through this example and cleaning up as I go).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Bindings/Python/IRModules.cpp | ||
---|---|---|
1046 | Nit: could you elaborate the type? I'm always confused if it is a PyContext or a PyContextRef. | |
1060–1063 | This behavior needs documentation. | |
1076 | Nit: can't we do throw py::value_error? | |
1181 | There may also be segmentSpec == 0 for optional operands. | |
1196 | Could we also complain if the result_segment_sizes is present but doesn't match the actual result structure? | |
mlir/lib/Bindings/Python/IRModules.h | ||
501–502 | Not sure if we actually want to swap operandList and resultTypeList | |
mlir/tools/mlir-tblgen/OpPythonBindingGen.cpp | ||
59 | The code also has 0 = optional element. | |
60 | Nit: trailing dot. |
- Addressed comments.
- Implemented full support for optionality in operands and results.
- Buffed up error messages.
- Implemented the first stage of support for default building regions.
PTAL
mlir/lib/Bindings/Python/IRModules.cpp | ||
---|---|---|
1060–1063 | We let our documentation get pretty out of date on this stuff. I've gone ahead and caught it up to present in these commits:
I then spent more time looking at this and refined it. Documentation and test cases are in this patch. I will follow up with more support for the related SingleBlockImplicitTerminator and region builder callbacks. | |
1076 | Updated, here and below. | |
1181 | Ok, I think I've now covered all of the optionality cases. | |
1196 | Not quite sure I follow: are you saying if someone called this with a result_segment_sizes attribute already set and then verify that what we computed matches it? Maybe just complain if it is present at all (I think that if you are working at that level, you should just be using Operation.create as the low level mechanism directly (versus this more "user level" entry point). I did this - lmk if you wanted something else. | |
mlir/lib/Bindings/Python/IRModules.h | ||
501–502 | This preserves the order of the existing Operation.create, and keeping the two in sync was my motivation in this patch. Given the commentary on https://reviews.llvm.org/D94810, let me start a thread on that topic, and then when we resolve it, I'll come back through and make everything consistent. I just don't want to diverge part-way with what we have now. |
mlir/lib/Bindings/Python/IRModules.cpp | ||
---|---|---|
1127 | It's being caught by the outer exception handler and put in parenthesis. |
mlir/examples/python/linalg_matmul.py | ||
---|---|---|
74 | This code isn't actually tested / built ? Are you missing some plumbing here? |
mlir/examples/python/linalg_matmul.py | ||
---|---|---|
74 | It's an example. And it runs standalone/doesn't need to be built. What should we do for things like this? There are likely to be a set of these things that are useful as samples and it doesn't make sense to organize as lit tests. |
mlir/examples/python/linalg_matmul.py | ||
---|---|---|
74 | I'm not sure what is the best way to plumb this through, but the goal should be that ninja check-mlir would exercise the code in the examples otherwise they'll bitrot. |
This code isn't actually tested / built ? Are you missing some plumbing here?