[Mlir-commits] [mlir] [NFC] Make AggregateOpInterface part of mlir:: instead of linalg:: (PR #70089)

[llvmlistbot at llvm.org]

================
@@ -0,0 +1,57 @@
+//===- AggregatedOpInterface.td ----------------------*- tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_AGGREGATEDOPINTERFACE
+#define MLIR_AGGREGATEDOPINTERFACE
+
+include "mlir/IR/OpBase.td"
+
+def AggregatedOpInterface : OpInterface<"AggregatedOpInterface"> {
+  let description = [{
+    This Interface is particularly useful in cases where we have an operation
+    that can be lowered into a sequence of simpler operations, thus essentially
+    decomposing an operation into a set of one or many simpler operations.
+    The operation being decomposed need to implement this Interface by implementing
+    the method `decomposeOperation` and return the set of values which would replace
+    the uses of the operation being decomposed.
+    Eg:
+        Assume there is an operation `CustomOp_Mul_Add` that takes in an input tensor
+        and a constant. It basically performs element-wise multiplication of the input
+        tensor with the given constant, and then performs element-wise addition of the
+        intermediate resulting tensor with the given constant.
+        `CustomOp_Mul_Add` can thus essentially be decomposed by implementing this
+        Interface.
+        `linalg::SoftmaxOp` is one such operation which makes use of this Interface
+        for implementing its decomposition.
+  }];
----------------
MaheshRavishankar wrote:

> I have a hard time seeing how this is something that composes across dialects or can just be reused generically. That seems quite "specific" to a specific pass at one given level of abstraction (and this is what makes it pretty contextual and not generic as I see it right now), and that's why it seems fine to me where it is.
> 
> For example would I implement this interface for the Arith dialect by splitting my `fma` into `add` + `mul`? This may be something I want for my use-case, but if I do this it'll be automatically picked up by the transformation when you apply it at the linalg level.

Yeah thats not the intent, but there is no way to codify it AFAICS. It is hard to predict where all these gets used. If there are issues with this, I am happy to go with one of two options
1) We keep the interface in Linalg...
2) We move the interface out of core into IREE...  Since there we have more control of which ops implement the interface, we can prevent unintended uses of it.


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