[Mlir-commits] [mlir] [mlir][linalg] Morphism across linalg named, category and generic ops. (PR #148424)

Renato Golin llvmlistbot at llvm.org
Wed Jul 23 07:39:05 PDT 2025


================
@@ -89,6 +89,44 @@ def LinalgInlineScalarOperandsPass : Pass<"linalg-inline-scalar-operands"> {
   ];
 }
 
+def LinalgMorphOpsPass : Pass<"linalg-morph-ops"> {
+  let summary = "Convert named op to category ops or generic and vice-versa";
+
+  let description = [{
+    Convert a linalg op from one representation to another equivalent.
+    For example, a linalg named op `linalg.add` can also be written as an
+    category op `linalg.elementwise`, and can also be re-written as
+    a `linalg.generic`, giving the morphism:
+
+      named-op <--> category_op (elementwise, contraction, ..) <--> generic
+
+    Generic is a bigger set than named and category ops and so not all generics
+    can be converted to single category-op or named-op. Similarly,  category
+     ops are  bigger set than named ops.
+
+    Note:
+     Legacy converters (will be deprecated):
+     `--linalg-generalize-named-ops` is the path `named-op --> generic-op`
+     `--linalg-specialize-generic-ops` is the path `named-op <-- generic-op`
+  }];
+  let dependentDialects = ["linalg::LinalgDialect"];
+
+  let options = [
+    // named-op <--> category <--> generic
----------------
rengolin wrote:

For now, this would do. It's not ideal, but it's something we can play with. I'm just worried that we'll end up creating a lot of deprecation notices for interim states. If people are fine with this, then designing this upstream is easier than downstream, so I'm ok with it as is.

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


More information about the Mlir-commits mailing list