[Mlir-commits] [mlir] [mlir][Transform dial] Expose convert-linalg-to-affine-loops transf (PR #211308)

Oleksandr Alex Zinenko llvmlistbot at llvm.org
Fri Jul 24 06:09:28 PDT 2026


================
@@ -4593,6 +4593,41 @@ DiagnosedSilenceableFailure transform::DecomposeWinogradOp::applyToOne(
   return DiagnosedSilenceableFailure::success();
 }
 
+//===----------------------------------------------------------------------===//
+// LinAlgToAffine
+//===----------------------------------------------------------------------===//
+
+DiagnosedSilenceableFailure transform::LinAlgToAffineOp::applyToOne(
+    transform::TransformRewriter &rewriter, linalg::LinalgOp target,
+    ApplyToEachResultList &results, TransformState &state) {
+  if (! isa<GenericOp>(target)) {
+    return DiagnosedSilenceableFailure::definiteFailure();
+  }
+
+  rewriter.setInsertionPoint(target);
+
+  FailureOr<LinalgLoops> generic = linalgOpToAffineLoops(rewriter, target);
+  if (succeeded(generic)) {
+    assert(! generic->empty() && "expected at least one loop");
+
+    // "generic" contains all new "AffineForOp", while we need to topmost one.
+    // Since all linalg operators are perfectly nested loops, these operators
+    //   are totally ordered through the ancestor relation.
+    Operation* opFirst = *(generic->begin());
+    for (auto itop = generic->begin(); itop!=generic->end(); itop++) {
+      if ( (*itop)->isProperAncestor(opFirst)) {
+        opFirst = *itop;
+      }
----------------
ftynse wrote:

Hmm, doesn't `linalgOpToAffineLoops` guarantee a specific order in which loops are returned? I'd expect it would.

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


More information about the Mlir-commits mailing list