[llvm-dev] ORC JIT Weekly #1

Tue Jan 28 13:35:07 PST 2020

Hi Andres,

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

> It's fine if the set of "somewhat stable" C APIs doesn't provide all the
> possible features, though.

Ok. This got me thinking about what a simple LLJIT API should look like. I
have posted a sketch of a possible API on http://llvm.org/PR31103 . I don't
have time to implement it just yet, but I would be very happy to provide
support and review patches if
anyone else wants to give it a shot.

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?

At a high level, ORCv2's design allows for basically the same features as
ORCv1, plus concurrent compilation. There are still a number of APIs that
haven't been hooked up or implemented though. Most prominently: Event
listeners and removable code. If you're using either of those features
please let me know: I do want to make sure we continue to support them (or
provide an equivalent).

There are no features supported by ORCv1 that require JITLink under ORCv2.

> - 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?

It's "kind of" supported. MCJIT and ORCv1 provided support for scanning the
llvm.global_ctors variable to find the names of static initializers to run.
This works fine when (1) you're adding LLVM IR AND (2) you only care
initializers described by llvm.global_ctors. On the other hand, if you add
object files (or loading them from an ObjectCache), or if you have
initializers not described by llvm.global_ctors (e.g. ObjC and Swift, which
have additional initializers described by metadata sections) then MCJIT and
ORCv1 provide no help out-of-the-box. This problem is further exacerbated
by concurrent compilation in ORCv2: You may need to order your initializers
(e.g. according to the llvm.global_ctors priority field), but objects may
arrive at the JIT linker out of order due to concurrent compilation.

The new ORCv2 initializer support aims to make all of this natural: We will
provide 'dlopen' and 'dlclose' equivalent calls on JITDylibs. This will
trigger compilation and execution of initializers that have not been run
already. If you use JITLink, this will include using JITLink-plugins to
discover the initializers to run, including initializers in metadata
sections.

-- Lang.

On Mon, Jan 27, 2020 at 10:14 AM Andres Freund <andres at anarazel.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200128/061ace30/attachment.html>