[Mlir-commits] [mlir] [MLIR][Python] Call `notifyOperationInserted` while constructing new op in rewrite patterns (PR #163694)

[llvmlistbot at llvm.org]

================
@@ -202,7 +207,15 @@ class PyRewritePatternSet {
           PyMlirContext::forContext(mlirOperationGetContext(op));
       nb::object opView = PyOperation::forOperation(ctx, op)->createOpView();
 
-      nb::object res = f(opView, PyPatternRewriter(rewriter));
+      PyPatternRewriter pyRewriter(rewriter);
+      nb::object listener = nb::cast(pyRewriter.getListener());
+
+      listener.attr("__enter__")();
+      auto exit = llvm::make_scope_exit([listener] {
+        listener.attr("__exit__")(nb::none(), nb::none(), nb::none());
+      });
----------------
PragmaTwice wrote:

> having a separate threadcontextstack just for listeners

yup it's possible and the code can be simpler by doing this. and even we don't need to make `listener` a python object.


> is this how listeners are actually composed? aren't there just like parent->child relationship

we can just have a threadlocal current listener instead of a stack, but to allow users to do weird nested things like this:

```python
def rewrite(op, rewriter):
    def rewrite2(op, rewriter): ...
    patterns = RewritePatternSet()
    patterns.add(.., rewrite2)
    ...

patterns = RewritePatternSet()
patterns.add(.., rewrite)
```

.. a stack can be more general (but i'm also not sure since this seems an anti-pattern..)

> passing in the listener to add (here) explicitly

this can be a little hard since `listener` is like a field of `PatternRewriter`, and outside the callback of `add` we cannot access the rewriter.

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