[Mlir-commits] [mlir] [MLIR] Fix ErasedOpsListener false positives for newly created ops/blocks (PR #188956)

[Matthias Springer]

================
@@ -61,16 +62,38 @@ struct WalkAndApplyPatternsAction final
 // ops/blocks. Because we use walk-based pattern application, erasing the
 // op/block from the *next* iteration (e.g., a user of the visited op) is not
 // valid. Note that this is only used with expensive pattern API checks.
+//
+// Ops and blocks that were *created* during the current pattern application are
+// exempt: they were not in the walk schedule before the pattern ran, so erasing
----------------
matthias-springer wrote:

As far as I know, newly-created ops (in the same block, but further down) are matched. We don't build a full worklist ahead of time. The documentation says `This driver does not (re)visit modified or newly replaced ops`, which is a bit confusing to me. What's a "newly replaced op"?

If I remember correctly, the reason why we have this expensive pattern check is to avoid iterator invalidation. Can you be sure that the iterator is never invalidated when erasing a newly-created op?



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