[Mlir-commits] [mlir] [MLIR][MemRef] Fix DimOfReifyRankedShapedTypeOpInterface IR-change on failure (PR #188973)
Mehdi Amini
llvmlistbot at llvm.org
Sat Mar 28 02:26:36 PDT 2026
================
@@ -90,13 +90,39 @@ struct DimOfReifyRankedShapedTypeOpInterface : public OpRewritePattern<OpTy> {
if (!dimIndex)
return failure();
+ // Save the op immediately before dimOp so we can identify and erase any
+ // ops inserted during the reification attempt if it fails. The
+ // pattern-rewrite invariant requires the IR to be unchanged on failure.
+ Operation *opBeforeReify = dimOp->getPrevNode();
+
+ // Erase any ops inserted between opBeforeReify and dimOp in reverse order
+ // to respect use-def chains within that range. Collect pointers first to
+ // avoid iterator invalidation: erasing a node in an ilist invalidates
+ // iterators to that node, and std::reverse_iterator stores the iterator to
+ // the *next* forward element, so make_early_inc_range(reverse(...)) would
+ // still dereference a stale iterator after erasure.
+ auto eraseInsertedOps = [&]() {
+ Block::iterator begin = opBeforeReify
+ ? std::next(opBeforeReify->getIterator())
+ : dimOp->getBlock()->begin();
+ SmallVector<Operation *> toErase;
+ for (Block::iterator it = begin; it != dimOp->getIterator(); ++it)
----------------
joker-eph wrote:
It'll go as far as new operations are added to the IR, but note that:
1) This only deletes when the rewriting actually fails
2) Most of the cost is already paid: useless operations were introduced before realizing the rewrite would fail.
So if we're concerned about compile time, we should figure out how to bail out early before creating these instructions.
https://github.com/llvm/llvm-project/pull/188973
More information about the Mlir-commits
mailing list