[Mlir-commits] [mlir] [mlir][linalg/scf/transform] scalable tiling and fusion for pack/unpack ops (PR #204007)

[Ege Beysel]

================
@@ -31,6 +31,19 @@ namespace scf {
 using SCFTileSizeComputationFunction =
     std::function<SmallVector<OpFoldResult>(OpBuilder &, Operation *)>;
 
+/// Computation function returning, for the op currently being tiled or fused,
+/// the per-iteration-domain-dimension `InnerTileAlignment` array to use (see
+/// `InnerTileAlignment`). The driver invokes it once per tiling/fusion of an
+/// op, so the returned array is always in *that op's own* domain -- the driver
+/// does not remap it. `tileSizes` holds the given tile sizes for pure tiling
+/// and is empty for fusion; `slices` holds the `tensor.extract_slice` (producer
+/// fusion) or `tensor.insert_slice`/`tensor.parallel_insert_slice`s (consumer
+/// fusion) being fused, and is empty for pure tiling. Only pack/unpack
+/// implementations consult the result; every other op ignores it.
----------------
egebeysel wrote:

Updated, thanks!

Technically speaking, it does not necessarily say that one of them should be non-empty. It is in the end a control function, you can pass a constant control function as well:
- Pure tiling driver (at the time of calling this control function) would have the tile sizes available, and passes it to the control function, because it might be useful information for the user.
- The fusion drivers work with slices instead, and those carry the information about the tile sizes (implicitly). These could be leveraged on the caller-side.

Realistically, this would allow the control function to dynamically confirm the confirm the loop tile size and inner tile size alignments with custom logic, but my use from the IREE side simply passes `Equal` for any scalable inner tile size with vector-level tiling, and `Multiple` for any scalable inner tile size with distribution-level tiling, since the tile size selection heuristics take care of these anyways.

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