- Providing stable, C-accessible definitions for bridging MLIR Python<->C APIs, we eliminate inter-extension dependencies (i.e. they can all share a diamond dependency on the MLIR C-API).
- Just provides accessors for context and module right now.
- Needed in NPComp in ~a week or so for high level Torch APIs.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir-c/PythonDefs.h | ||
---|---|---|
69 ↗ | (On Diff #294725) | Isn't the isError redundant with returning a null context ? |
94 ↗ | (On Diff #294725) | Why isn't this file in the Python binding directory? |
mlir/lib/Bindings/Python/IRModules.cpp | ||
462 | What about zero initializing explicitly? Reading such code is always suggesting me to read the implementation of the callee to make sure there isn't a path where it won't set the error flag. | |
mlir/lib/Bindings/Python/IRModules.h | ||
210 | Is this useful right now on the Module? |
Thanks!
mlir/include/mlir-c/PythonDefs.h | ||
---|---|---|
69 ↗ | (On Diff #294725) | Ah, we were missing an mlirContextIsNull and I just wasn't thinking (Alex still wants these structs to be mostly opaque from user's perspectives). Added it and removed the arg. |
94 ↗ | (On Diff #294725) | My mistake: I was considering the right place high order bit to put it in to be mlir-c but then neglected to create the sub-directory. Moved to mlir-c/Bindings/Python/Interop.h. |
mlir/lib/Bindings/Python/IRModules.cpp | ||
462 | I think how this is now side-steps the concern, but let me know if not? (not quite following what you want to zero-initialize here) | |
mlir/lib/Bindings/Python/IRModules.h | ||
210 | I have a use for it in npcomp and am working around it not existing (basically, want to allocate a Python-visible Module and also interop with it at the MLIR-C API level). |
mlir/lib/Bindings/Python/IRModules.cpp | ||
---|---|---|
462 | Yes LG, it was the output parameter isError that is removed now. |
Is this useful right now on the Module?