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

[Quinn Dawkins]

================
@@ -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);
----------------
qedawkins wrote:

> It is unclear to me when it cannot reuse getTiledImplementation? Do you have a specific operation in mind?

I'm not sure about the current implementation, but I could see this being the case for `tensor.pad`. Tiling based on the operand must produce the entire padded tensor near the boundaries (and thus can always tile to another `tensor.pad`), but tiling based on the full iteration space of the result could instead produce `scf.if { } else` to avoid dynamically zero-sized tensors. In other words, tiling based on the operand could be a restricted subset of tiling for the whole operation and thus want a different implementation.

> Ok, I think this PR has been put through the review wringer a bit too much. I dont think we should use PRs as a way to bike shed ideas.

Good point and I contributed to this. I'm going to avoid extending the conversation here then and wait for an RFC or another place to discuss. I, and it seems others as well, have work dependent on this change so I would like to see it land in some capacity sooner rather than later, but that should not be a forcing function. Otherwise, the lit tests in this PR look good to me so I'll keep my approval as is for those portions.

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