[Mlir-commits] [mlir] [MLIR] Add continuous tiling to TileUsingForOp (PR #82792)

[llvmlistbot at llvm.org]

================
@@ -1409,16 +1409,27 @@ def SplitOp : Op<Transform_Dialect, "structured.split",
     operations pointed to by the target handle.
 
     The operation consumes the target handle, but preserves the split point
-    handle if provided. It produces two new handles pointing to the two parts
-    of the structured op after splitting, in the same order as the target
-    operand, with the first handle corresponding to the part with lower
-    iteration space indices.
+    handle if provided. Without the `multiway` attribute, it produces two
+    new handles pointing to the two parts of the structured op after splitting,
+    in the same order as the target operand, with the first handle
+    corresponding to the part with lower iteration space indices.
+
+    Multiway split mode is enabled by specifying the `multiway` attribute.
+    In this mode a single `target` op is split into multiple parts covering
+    the iteration space of the specified dimension. `static_split_point` and
+    `dynamic_split_point` in this case is a list of chunk sizes that the given
+    dimension should be split into. With `multiway` it produces two handles;
+    the first handle is a list of the multiple parts of the structured op
+    after splitting, where the target dimensions for each linalg op in the
+    list corresponds to the chunk sizes specfied in the input split list.
+    The second handle is empty.
----------------
muneebkhan85 wrote:

I have tested this out. It can surely be a single handle and can be split into multiple handles using split_handle, though there's a caveat that split_handle needs to specify the expected number of outputs (as list of output types) depending on the number of payloads it receives in the handle.

In the multitile-size example `mlir/test/Dialect/Linalg/multisize-tiling-full.mlir` the 2nd split op generates two lists that are used by the two subsequent `tile_using_for`. Creating a single output for the split op would mean merging these two lists and `split_handle` would then see a handle of 4 payloads. This complicates things a bit in the sense that some reworking of the usage and examples are needed. Keeping it to produce two outputs for now. I think this change would be good for a separate PR.

https://github.com/llvm/llvm-project/pull/82792