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

[Abhishek Varma]

================
@@ -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.
+  }];
----------------
Abhishek-Varma wrote:

> also the Aggregate naming confused me because Aggregate is how LLVM named "struct" types).

Oh okay, I understand. We can change the naming here perhaps, in that case.

> I still don't know when I would use this interface and ask to "decompose" such an operation, what is the use-case?

I understand your point. I'll try to explain the use-case which necessitates this NFC change.
So, the idea is to perform [a similar operation like linalg::Softmax](https://github.com/llvm/llvm-project/blob/85f6b2fac9a367337e43ca288c45ea783981cc16/mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp#L2550) for a few other [Linalg-Like operations in IREE](https://github.com/openxla/iree/pull/15294) by implementing [the already defined upstream interface](https://github.com/llvm/llvm-project/blob/85f6b2fac9a367337e43ca288c45ea783981cc16/mlir/include/mlir/Dialect/Linalg/IR/LinalgInterfaces.td#L820) used by [linalg::Softmax here on top-of-main](https://github.com/llvm/llvm-project/blob/85f6b2fac9a367337e43ca288c45ea783981cc16/mlir/include/mlir/Dialect/Linalg/IR/LinalgOps.td#L97) and then instead of having separate individual passes for their decomposition, we only have one pass which would do the needful.

I'm not sure if we're discussing about removing this interface altogether from top-of-main now or we shouldn't move it from `linalg::` namespace to a more generic namespace - since the Interface already exists.

Can you confirm once? @joker-eph 

Also, perhaps @MaheshRavishankar can add a better context here if I missed any pointers pertaining to the use-case.

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