[Mlir-commits] [mlir] [mlir][python] C++ API demo (PR #71133)

[Maksim Levental]

makslevental wrote:

Regarding footguns

> That seems like a dangerous pattern to me: what happens when print_ops goes out of scope? (I mean it can't here, but you're registering a `PyObject` so it could...)
> 
> Also can you write in the same file a second run of the pipeline with a different `print_ops` which would print with a prefix for example? I suspect the registration being global that won't work...

and

> This pulls in mlir c++ libs (built-in and pass) but it's not depending on them here. It appears they just happen to be resolved via MLIRCAPIPythonTestDialect.

Hence the name of the branch being `hold_my_beer` :smile:. I fully admit this isn't for the faint of heart but the functionality implied is really very "powerful" isn't it? Build a pass to do some rewrite as a function of say calling `networkx` or an ILP solver but you don't need to link anything at runtime or compile, just munge some Python. Anyway it doesn't matter to me if it doesn't get merged. The PR basically already serves the purpose of being a minimal POC.

> but will not work with hidden visibility, like real packages use.

This one I thought of and I will need to solve in the other places I intend to use this - my thought is to statically link everything (the aggregate and the extension modules) into one shared object (like Triton does) and then private symbols aren't a problem.

> Not only will it duplicate the backing library code in the extension, TypeID linkage will no longer be single, strongly rooted. This will create the dreaded vague linkage issues on Linux and has no path to work on Windows.

Yes I've tried this and of course you get that problem and it shows up as "duplicate registrations" for things dialects and passes and etc. Again my thought is keeping everything in shared object file solves these problems but maybe I'm wrong.

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