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

[Oleksandr Alex Zinenko]

================
@@ -131,6 +150,42 @@ def TilingInterface : OpInterface<"TilingInterface"> {
           return failure();
         }]
       >,
+      InterfaceMethod<
+        /*desc=*/[{
+          Method to generate the tiled implementation of an operation from
+          operand tile position.
----------------
ftynse wrote:

> I tried following the other comment regarding the same which now makes this as a static method instead. Does that work? The idea is to have a unified API which tensor::replaceInsertSliceWithTiledConsumer can use.

A "non-overridable" method would work. It's not be a static method (we have "static interfaces" that have "static methods" overridable by a specific subclass but not requiring an _instance_ of that subclass to execute). We have `extraClassDeclarations` and `extraSharedClassDeclarations` on interfaces that can be used for this purpose. (Don't take inspiration from the Linalg interface, it overuses overridable methods for things that shouldn't be overridable.)

> I'm not sure if I understood the question (moreover the intent) of this question. Did you mean to say what happens if two given ops are implementing these methods in an orthogonal way? In that case I'm failing to see how that's an issue if the implementation achieves what the method is aimed for.

The current design has overridable methods to do A->B, B->C and A->C. (where A is the operand tile, B is the iteration domain tile, and C is the tiled implementation). It is a dangerous design because the implementation that overrides them must guarantee that A->B->C and A->C produce the same result. And given the complexity of each of these functions this is far from being obvious to verify, let alone implement. So I am suggesting that A->C (this method) should not be overridable at all. 

There may be a case where there exists a more efficient implementation of A->C than doing A->B->C, which would justify making it overridable with a default implementation. I would like to see such a case before doing that. 

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