[Mlir-commits] [mlir] [MLIR][Linalg] Add aggregate ops decomposition pass and softmax decom… (PR #97582)

[Rolf Morel]

================
@@ -1317,25 +1317,21 @@ def ConvertToLoopsOp : Op<Transform_Dialect, "structured.convert_to_loops",
 def DecomposeInterfaceOp : Op<Transform_Dialect, "structured.decompose_interface",
     [FunctionalStyleTransformOpTrait,
      MemoryEffectsOpInterface,
-     TransformOpInterface,
-     TransformEachOpTrait,
+     DeclareOpInterfaceMethods<TransformOpInterface>,
      ReportTrackingListenerFailuresOpTrait]> {
   let description = [{
-    TODO
+    Decomposes high-level named ops into a sequence of non-aggregate named ops
+    via `AggregatedOpInterface`.
+
+    The operation ignores non-decomposable ops. The return handles point to
+    a sequence of named ops produced by the decomposition.
   }];
 
   let arguments = (ins TransformHandleTypeInterface:$target);
-  let results = (outs TransformHandleTypeInterface:$transformed);
+  let results = (outs Variadic<TransformHandleTypeInterface>:$transformed);
----------------
rolfmorel wrote:

> The other option I considered was to assign all the resulting ops to the single value the transform op returns. That had the downside of not knowing which new payload corresponds to which target

I think this is also a valid option, namely keep the op vectorized but it's up to the user to deal with the information loss of which decomposed ops belonged to which op in `target`'s payload. For example, if you know you want to do the same thing to all decomposed ops anyway, e.g. generalize them, this would be more compact than needing use a `transform.foreach` and stuffing the `decompose_interface` op in it's region. In case the user ensures there's only one op associated to `target`, e.g. by using `transform.foreach`, then they regain the unambiguous semantics of my suggestion.

You could even make the "accumulation" behaviour opt-in by requiring the user to use a (unit-)attribute or keyword. Whether this is a pattern that is desirable for the transform dialect is I think best addressed by @ftynse.

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