I think LLVM has had at least three APIs for dynamic code generation - the 'legacy' one until 3.5 (don't think it had a name?), MCJIT, and ORC. This one looks more like it's optimising the user interface, and using a kind of DSL with modern C++ features.
And in fact one of the ongoing problems with LLVM is that the interface churns so much. As a user it's a huge pain to keep up and to make sure there are no regressions. (And keep in mind this also includes performance, code size, debugging... it's not just about correctness.)
I don't know if stability is a goal for this project but personally I'm hoping someone comes along and makes a stable LLVM interface (and manages to be successful with it).
this topic pop up in eurollvm this year again: the LLVM C API is, and should be the only stable API. Others like C++ API or even ABI stabilities can only be considered as best-efforts.
Can we at least make the C API more feature complete so that it's a plausible target for more users? As far as I know it's not really a viable target for a heavy-duty user like a language compiler backend.
Cling takes C++ and interprets it like a REPL would. CodeGen is a JIT compiler that takes what's essentially an IR and uses LLVM to generate assembly from it.
Definitely interesting. I have a couple questions:
1. Quite confused about actual use cases, could anybody come up with an example?
2. The way I see it, it's kind of a way to have run-time "macros"?
3. How much overhead does this have when shipping the code to the user?
4. Would it be difficult to implement something like this for Rust? I can see special syntax to define the functions, would it make sense to add language support for this feature?
One prominent use case is: you can generate linear algebra kernels that are specific to both the shape of your data and the hardware features of the machine on which the kernel is run (i.e. on a Xeon use AVX512, on desktop use AVX2, or on really old desktop use SSE). Therefore you can avoid hand-coding dozens of specializations of such kernels beforehand.