[Mlir-commits] [mlir] [MLIR][SCF] Add an API to fuse consumer to a producer within scf loop (PR #88712)

[llvmlistbot at llvm.org]

================
@@ -160,6 +215,21 @@ struct LinalgOpTilingInterface
     return success();
   }
 
+  FailureOr<TilingResult> getTiledImplementationFromOperandTile(
+      Operation *op, OpBuilder &b, unsigned operandNumber,
+      ArrayRef<OpFoldResult> offsets, ArrayRef<OpFoldResult> sizes) const {
+    SmallVector<OpFoldResult> mappedOffsets, mappedSizes;
+    auto tilingInterfaceOp = cast<TilingInterface>(op);
+    if (failed(tilingInterfaceOp.getIterationDomainTileFromOperandTile(
+            b, operandNumber, offsets, sizes, mappedOffsets, mappedSizes))) {
+      return emitError(
+          op->getLoc(),
+          "unable to obtain the iter domain position of the operation.");
+    }
+    return tilingInterfaceOp.getTiledImplementation(b, mappedOffsets,
+                                                    mappedSizes);
----------------
MaheshRavishankar wrote:

> My thinking here is that `getTiledImplementation` does too much. It should not be emitting IR that computes a slice of each operand. Instead, it should be _given_ such slices. These slices in turn can be obtained from a separate `getOperandTileForIterationDomainTile` method (though I'm not sure whether this should be a method on the operation interface, or we should introduce a "TileableData" type interface that is implemented by tensors and potentially other types). This method would be called by "pure" tiling and producer fusion, and would not be called by consumer fusion _for the operand that comes from the producer_ (it will still be called for _other_ operands). Instead consumer fusion will directly supply `getTiledImplementation` with the slice of the operand that is just the result of the tiled producer (before `insert_slice`). This would also work if we were to introduce, e.g., nested linalg generics that folks have been discussing for years, where the data tiling of operands would be part of the surrounding generic that acts as a loop; as well as for the cases of non-hyperrectangular data structures.

I have strong concerns with this. `getTiledImplementation` is necessarily black boxed. I would not want to assume that you can produce an implementation of tile from the slice. Also it seems backwards to me to compute the slice of the operands, then pass it to the tiling implementation to say produce the tile. It is much more natural to just pass the slice of the iteration space and let the operation implementation handle the slicing/dicing of the operands/results. Adding more data structures, and semantics should all layer on top of this as a "specialization".  In my mind, if thats the core method then that betrays the motivation behind how `TilingInterface` is structured.

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