[llvm-dev] ORC JIT Weekly #1

[Andres Freund via llvm-dev]

Hi,

On 2020-01-16 18:00:53 -0800, Lang Hames via llvm-dev wrote:
> In the interests of improving visibility into ORC JIT development I'm
> going to try writing weekly status updates for the community. I hope
> they will provide insight into the design and state of development of
> LLVM's JIT APIs, as well as serving as a convenient space for
> discussions among LLVM's large and growing community of JIT API users.

That's a great idea.


> Since this is the first update, I have also added some highlights from last year, and the plan for 2020.
> 
> Highlights from 2019:
> 
> (1) ORCv1 was officially deprecated in LLVM 9. I have left it in for
> the LLVM 10 branch, but plan to remove it from master in the coming
> weeks. All development effort is now focused on ORCv2. If you are an
> ORCv1 client, now's the time to switch over. If you need help please
> ask on the llvm-dev mailing lists (make sure you CC me) or #llvm on
> discord. There are also some tips available in
> https://llvm.org/docs/ORCv2.html

I also want to highlight the necessity of some form of C API, that
others already have.

Besides just needing something that can be called from languages besides
C++, some amount of higher API stability is also important. For users of
LLVM with longer support cycles than LLVM (e.g. Postgres has 5 years of
back branch maintenance), and which live in a world where vendoring is
not allowed (most things going into linux distros), the API churn can be
serious problem.  It's fine if the set of "somewhat stable" C APIs
doesn't provide all the possible features, though.

It's easy enough to add a bunch of wrappers or ifdefs hiding some simple
signature changes, e.g. LLVMOrcGetSymbolAddress adding a parameter as
happened in LLVM 6, but backpatching support for a larger API redesigns,
into stable versions, is scary.  We do however quickly get complaints if
a supported version cannot be compiled due to dependencies, as people
tend to upgrade their OS separately from e.g. their database major
version.


> (2) LLVM has a new JIT linker, JITLink, which is intended as an
> eventual replacement for RuntimeDyld. The new design supports linker
> plugins (allowing operation on the low-level bits generated by the JIT
> linker) and native code models (RuntimeDyld required a custom code
> model on some platforms). Currently JITLink only supports Darwin
> x86-64 and arm64, but I hope to see support for new platforms added in
> the future.

What's the capability level of ORCv2 on RuntimeDyld compared to ORCv1?
Are there features supported in v1 that are only available on JITLink
supported platforms?


> - Improve JIT support for static initializers:
>   - Add support for running initializers from object files, which will enable loading and caching of objects containing initializers.

Hm, that's kind of supported for v1, right?


Greetings,

Andres Freund