[Mlir-commits] [mlir] [MLIR][Python] remove `liveOperations` (PR #155114)

Maksim Levental llvmlistbot at llvm.org
Tue Aug 26 12:31:16 PDT 2025


================
@@ -216,13 +216,8 @@ added to an attached operation, they need to be re-parented to the containing
 module).
 
 Due to the validity and parenting accounting needs, `PyOperation` is the owner
-for regions and blocks and needs to be a top-level type that we can count on not
-aliasing. This let's us do things like selectively invalidating instances when
-mutations occur without worrying that there is some alias to the same operation
-in the hierarchy. Operations are also the only entity that are allowed to be in
-a detached state, and they are interned at the context level so that there is
-never more than one Python `mlir.ir.Operation` object for a unique
-`MlirOperation`, regardless of how it is obtained.
----------------
makslevental wrote:

The `valid/invalid` system is still present/functional but I'm deleting this because now `PyOperation` can alias each other. I'm not 100% sure what the risk/fear here is because if you mutate `py_op1` (say delete some other operations in its contained region) and then walk `py_op2` you will indeed see the correct AST (because both Python objects are wrapping the same `mlir::Operation` after all). The only thing that has changed is that Python if you invalidate `py_op1` then as of this PR `py_op2` will not know about this invalidation. But this falls under the umbrella of transforming a root and then expecting anything under the root (**including the root**) to remain valid (if something is in fact invalidated).

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


More information about the Mlir-commits mailing list