Does anybody know of existing NodeJS to MLIR bindings?
Or the good design pattern for creating such bindings?
I’m not aware of any. What are you looking to do with the bindings?
Historically, iree had maintained python bindings sufficient to parse/print the asm form of modules, run passes, compile artifacts, etc. This typically just involves wrapping a few facilities of MLIR to implement more of a compiler-frontend like thing. Example.
A level up from that you have IR generation, which can be made relatively memory-safe and is mostly write-only. @nicolasvasilache built a version of this style (again for python) focused on having a fairly literate interface for user-centric metaprogramming. This was dropped from the repo when it moved to LLVM but I have an up to date version here.
Going further, you can have bindings that more mirror the core APIs and allow fine-grained, low level manipulation of the IR. I don’t believe it is feasible to make such a binding that is both full featured and safe since the lifetime of parts of the IR does not match any kind of memory model that dynamic languages provide: while some of the core structures can be made memory safe, it is always possible to manipulate the IR in a way that invalidates pointers. This level of binding can still be useful for lower level tools, JIT compilers, etc. Again, python, but here is an example of that level of binding.
In general, I think that the project has not figured out its position on bindings that go beyond the C and C++ APIs. Most of the investigations I’m aware of in this area are wrt python, which has a lot of affinity with the math and ML community, which was very involved in the startup phases of MLIR, and is still where a lot of momentum is coming from. There is a GSOC project starting next week to build some level of other bindings in-tree but it has not yet answered questions about what level or type to pursue. I feel that examples of things that are useful are pretty valuable at this point.
1 Like
Stella,
Thank you for the detailed answer and links. I will read all of them. I am very new to MLIR, so forgive me if my terminology is off.
My immediate goal is to have JS API to be able to construct MLIR nodes of specific dialect, and connect them. I would also need an API to kick MLIR transformation chain, and emitter.
NodeJS has a robust way of creating native Addons with C++ bindings. Node-API | Node.js v14.20.0 Documentation
I plan to read more on MLIR APIs and NodeJS NAPI bindings, and see how it goes.
Thank you again,
Aliaksei
That is completely reasonable to want to do. It’s been many years since I’ve worked at that level of nodeJS but the facility seems like what I would expect. The trickiest part, as I mentioned, will be modeling the IR manipulations that invalidate pointers and deciding how/if to bridge that to the JS side).
I’d have a look at mlir_edsc.cpp as I linked above (there is a filecheck test next to it). In practice, I also needed some lower level facilities once I got past a basic prototype, which is why I created mlir_ir.cpp as more of a 1:1 API mapping (with unsafe access to the IR). In addition, I was fiddling with some python level wrappers for creating ops/types/attributes in my custom dialects (see dialect/Numpy.py). I had a thought to unify all of this (ideally the edsc layer can interop with the more direct API mapping and there may be a role for tablegen to autogenerate things like my Numpy.py), but I don’t have the cycles on this project to explore all of that at once… It seems like there could be a nice story there, though.
All references above are to files here.
1 Like
Thank you, Stella. It all make total sense.
Another attractive option I have in mind is to compile into WebAssembly and bind via WASI
This will allow safer binding not only to NodeJS but JS in browser, and other languages.
We had some initial thread about WASI in the old repository:
1 Like
Sounds interesting. On the IREE side, we have various hopes/interest in various intersections with webassembly but nothing rising to the level of plans. I think we’re more interested at this point in emitting webassembly than embedding the compiler, but there are a lot of interesting potentials on that side too. I’d be interested in hearing about any progress you make!
1 Like
Hey Aliaksei,
Would a good C binding help? I’m not familiar with JS binding approaches, but a C binding can be used by many languages.
-Chris
Yes, Chris,
C bindings will help a lot. They can be wrapped with NodeJS Native addon API or/and can be exported by the WebAssembly module.
Awesome - MLIR has some prototype C bindings available in the mlir/include/mlir-c directory, following the pattern of the LLVM C bindings in llvm/include/llvm-c. It would be great to build those out to support construction of the entire set of IR constructs. If you’re interested in working on this, I can help review the patches etc.
-Chris
1 Like
@zhanghb97 who is starting a GSOC project in this area next week. Building out/using the C API was one of the options discussed.
Fwiw, I think a full C API is a more important thing to build upstream than language specific bindings. And I’d be really interested to see how it works out in practice to build c-ffi based language support in node/python/whatever. I’ve seen a couple of cases where I feel like this produced an API that felt right from the target language perspective, but I’m not convinced in general (or with something intricate like MLIR specifically) – the proof is in actually building it and assessing. Even if it turns out that the pythonistas (of which, I am one 
) eventually create something specific for themselves, starting with a full featured C-API is probably the best choice for the project at this point.
Also happy to review C-API patches.
1 Like
I feel like I want to laugh but am not getting the joke!
I plussed them in for visibility to this discussion, which is relevant to their project.
Oh I wasn’t aware of that, thank you for bringing that up!
1 Like
Agree, that plain C API is a great target.
WASM would require just exporting them up Notes on working with C and WebAssembly
Oh sorry… I just meant that nothing is confirmed before 18:01 UTC on May 4 right?
It is a leak, according to GSoC rules. But we like: 
Apologies everyone for jumping the gun (I should really read those rules and assumed that since it had been discussed at some length in the Beginners channel that I was being helpful by bridging the conversations) – I have no actual involvement with the project or participant beyond having discussed it on the beginners thread and since I don’t know any more than what is on that thread, I don’t think we’ve actually leaked anything in this convo in practice
Ok, so he could start or not next week, who knows
People who know me well know to never trust me with any high precision information regarding times and dates, so this is well within the uncertainty window of how I live my life
I’ve just been eagerly waiting for the project to either start or not start, by a person who may or may not have engaged on that thread. So I’ll just carry on with that hope.
1 Like