[Mlir-commits] [mlir] [mlir][python] Make the Context/Operation capsule creation methods work as documented. (PR #76010)
Oleksandr Alex Zinenko
llvmlistbot at llvm.org
Fri Dec 22 04:57:32 PST 2023
ftynse wrote:
> I might add an arg to indicate whether ownership must be transferred.
Yeah, this is likely the sanest approach. Maybe we were wrong about not exposing ownership in C API types since it makes it harder to map the API to languages that do have explicit ownership.
One thing that I find tricky here is the "transitive" ownership of IR objects. On the C++ side, the caller has ownership of the top-level module and potentially some detached operations. In Python, we seem to be modeling that Python user owns any operation they have a reference to, which isn't strictly necessary. Though we might not want to traverse the IR every time something returns a `MlirOperation` to check whether a parent is already owned.
Same may happen with contexts by the way. We just never have a need to return an `MlirContext` from functions because all Python code is executed in a `with Context` block anyway.
I don't know offhand if we can just mimic C++ ownership rules and somehow require Python client to keep the top-level module alive rather than say that any reference into the connected IR blob maintains all of it alive.
> I'll take this opportunity to beat my favorite dead horse: we could just start exposing the utilities in lib/Bindings, such as PyOpreationRef, in order to avoid the inherent difficulties of relying on only PybindAdaptors.h to always do the right things.
We can go the other way around and eat our own dogfood by actually using PybindAdaptors.h upstream...
https://github.com/llvm/llvm-project/pull/76010
More information about the Mlir-commits
mailing list