[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