[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