[Mlir-commits] [mlir] [MLIR][Python] Add a function to register python-defined passes (PR #157850)

[Rolf Morel]

rolfmorel wrote:

Thanks @PragmaTwice - this is good functionality to have!

Having said that, I feel the design of passes-are-functions-with-metadata is showing its limitations. I note the following "strikes against" (and contrast them with a class-oriented design):
1. needing to pass in an object to call a method on to signal pass failure - https://github.com/llvm/llvm-project/pull/157613
    * `signal_pass_failure` could just be a method that an instance of a Pass calls on its base class 
2. needing to pass dependent dialects as metadata - https://github.com/llvm/llvm-project/pull/156000#discussion_r2310595659
    * this could just be a static property of the class that inherits `Pass`. Registration could use this static property. 
3. needing to share `__call__`-implementing objects among pass managers - this PR.
    * if the registration method took a class definition (or some other factory for objects), there would be a lack of surprise regarding objects/instances being shared among pass managers. That is, it would be the same as on the C++ side.

I know you and @makslevental have already looked at alternatives, in particular, a class-based design and noted issues. Regarding @makslevental's [comment](https://github.com/llvm/llvm-project/pull/156000#discussion_r2330296999):
> you have to create the object in C++ in order for the unique_ptr magic to work. So that won't blend with "subclass and instantiate a nanobind class in Python".

Could it work if we pass the class object to the bindings and have the right callbacks instantiate the class from the C++ side? Presumably that would mean C++-code gets to manage the lifetimes of the instances. Maybe taking a weakref to the class definition would be enough (as the class definition should _normally_ live until the end of the Python runtime).

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