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

[Ege Beysel]

================
@@ -66,6 +66,57 @@ struct MergeResult {
   SmallVector<Value> replacements;
 };
 
+/// Per-dimension alignment of a loop tile size to a `linalg.pack` /
+/// `linalg.unpack` inner tile size, supplied by the caller (which performed the
+/// tiling and knows both the tile sizes and the inner tiles) so that
+/// pack/unpack TilingInterface implementations need not re-derive it from the
+/// materialized IR. An absent entry (or `Unknown`) means "no information": the
+/// implementation must fall back to its prior behavior for that dimension.
+///   - `Multiple`: the loop tile size is an integer multiple of the inner tile.
+///   - `Equal`:    the loop tile size equals the inner tile size.
+///
+/// This is a caller assertion, not a checked fact: it is only consulted when
+/// the relationship cannot be decided from the IR (e.g., scalable or dynamic
+/// sizes). When the tile and inner-tile sizes are both statically known,
+/// implementations trust that static comparison instead, so a hint that
+/// contradicts statically known sizes is ignored rather than allowed to produce
+/// incorrect tiling. The hint is otherwise never verified, so an incorrect
+/// assertion produces silently invalid tiling.
+///
+/// Entries are indexed by the dimensions the consulting method reasons about,
+/// i.e. the op's iteration domain (in pre-interchange order -- `interchange`
+/// reorders the generated loops only). This also holds for the
+/// `*FromOperandTiles` consumer-fusion methods: for a pack the iteration domain
+/// coincides with the unpacked operand's source dimensions, while for an unpack
+/// the entry for the i-th inner tile sits at its dest dimension
+/// `inner_dims_pos[i]` (a dimension of the unpacked tensor, not of the packed
+/// operand). Entries are not remapped through indexing maps or
+/// `outer_dims_perm` (for a transposing pack they stay in source order,
+/// pre-permutation), so the caller must pre-arrange them to match that order.
----------------
egebeysel wrote:

Ok, you're right. Neither of those paragraphs belonged there IMO, so I moved these explanations to the corresponding call-sites and only left the actual documentation of the enum in-place.

For your clarificiation:
- `entries` correspond to the indexing map between the passed array of alignment hints, and the tiling dimensions of pack/unpack.
- the interchange order is not relevant here per-se, it's a bit more prominent if we were to look at the tests: the order of the actual loops in the IR (post-interchange order), and the order of the hints (pre-interchange order) not corresponding to each other was what I meant, but I deleted that because it leads to confusion instead. The test site is a better place to showcase this.

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