[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.
+  }];
----------------
qcolombet wrote:

> 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.

That's a good point and I believe we wouldn't want that thing to be picked up at the linalg level. That being said, this is transformation specific, meaning we could have the transformation pick the level it wants or all levels if it is what the specific use case is. E.g., `if op.implementThisInterface and op.isDialect(linalg)`. I'm not saying this is what we want (nor if it is even possible), but assuming it is, then that could be a way to have the interface being more controllable.

Not arguing either way for this PR (accept or reject), ultimately what I wanted to achieve with the original PR (admittedly without giving it much thoughts) was to do a better job at describing / discovering what is supported by the conversion patterns and what should be expanded before conversion. The idea of this interface was to capture what needed to be expanded.

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