[llvm-dev] Orc JIT v1 Deprecation

[Alex Denisov via llvm-dev]

Hi folks,

Rather by accident than on purpose I looked at the release notes and found the following:
http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-jit-apis

TL;DR: Orc v1 is deprecated and will be removed in the next release.

I have several questions in this regard:

1. Is there a migration guide I can use to update my code to the new version?
2. Is there any development plan for this part of LLVM? So far I have feeling that it's a closed source development.
3. Is there some communication channels I am missing to follow? I follow dev&commits mailing lists and present on IRC once in a while, but I somehow missed the message about the Orc v1 removal.

Also, the release notes mention that Orc v2 is the recommended way for the new projects, but:

1. Is there a documentation?
2. How stable the APIs are?

Thank you,
Alex.

[Praveen Velliengiri via llvm-dev]

Hi Alex 

Sorry for late reply

The New ORC APIs support concurrent compilation.

I'm not aware of any migration guide to ORC v2 from v1. But there is a in-tree classes called LLJIT and LLLazyJIT which is an example for using new ORC APIs.

You can also take a look at "Updating ORC for Concurrency" talk by lang hames, the talk explains about the new APIs. I hope discussions about JIT is generally available in LLVM-dev mailing lists.

For documentation kaleidoscope, I don't think the updated version is available yet.  And I personally hope APIs are stable enough, and also there is an effort to add speculation to JIT which modify the internals to support that but APIs will mostly be the same, but not sure there may be a some changes in future.

Also CC'ing Lang Hames for more insights

Thanks

Praveen

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Praveen Velliengiri via llvm-dev]

Hi Alex

Correction : Kaleidoscope chapter 1 & 2 are up-to-date. But chapter 3..5 are not.

[Christian Schafmeister via llvm-dev]

I thought I would add a data point.

I implemented the Orc v1 API in Clasp - an implementation of Common Lisp that uses llvm as the backend. 

Recently, I switched over to using the new API - works great!  I'm very excited about the work Lang has been doing and I'm excited to hear that there is a fix for lldb debugging of jitted code coming (thanks Stefan!).

Orc v1 API Clasp:  (https://github.com/clasp-developers/clasp/tree/dev) 

New Orc API Clasp:  (https://github.com/clasp-developers/clasp/tree/dev-llvmtot)

It's a bit weird because Clasp is self-hosting and I expose the llvm API's to Common Lisp and I use the llvm API's in a combination of C++ code and Common Lisp code.

On Fri, May 17, 2019 at 3:35 PM Stefan Gränitz <stefan....@gmail.com> wrote:

I agree, the deprecation of Orc v1 should come with more guidance and preparation than currently available. I don't think you are missing any channel. The main sources of information are code and reviews. I gathered some data on typical lines of argumentation below. Maybe it makes sense to have look at them in isolation.

TL;DR: While I do have a number of proposals for the points in the end, I would first like to hear your opinions.

(1) MCJIT can be considered mature and stable, while Orc is experimental:
* Orc is in trunk for more than 4 years now [1]
* tutorials moved to Orc with Release 3.8 (3 years ago) [2]
* "ORC should be preferred for new projects" made it to the official release notes only now, with 8.0
* it's a common statement on the list since many years [3]

(2) The LLVM test suite has various use-cases for lli, so the JIT gets exercised well. Grepping through lit tests on master today gives me:
* 202 matches for lli in total (regex: RUN.*[% ]lli)
* 80 matches for lli using Orc v1 (regex: RUN.*[% ]lli.*jit-kind=orc-mcjit)
* 17 matches for lli using Orc v2 (regex: RUN.*[% ]lli.*jit-kind=orc-lazy)

(3) There are few active stakeholders in LLVM JIT development:
* ExecutionEngine saw about 250 commits in total during the last year (looking at: llvm/include/llvm/ExecutionEngine && llvm/lib/ExecutionEngine)
* 192 of these are from Lang, most of the remaining one's are either not touching the JIT or NFC
* I just submitted a fix for JITed code debugging in LLDB, which was broken since Release 5.0 [4]

Conclusions?
* All newcomers go with Orc, because the tutorial uses it and the list recommends it.
* Some newcomers became clients. Their projects got mature and they ask for a more stable API.
* We saw drastic API changes in Orc with past releases. Upcoming releases should account for the rate of adoption more and more.
* Most clients stay clients. Certainly, there are many reasons for that. Anyway, we need more active participation.

It's time to:
* Switch lli's default to Orc to increase visibility and test coverage. Of course, MCJIT-specific tests should pass -jit-kind=mcjit.
* Agree on a way forward, at least for the current release, so we can carve out small/simple tasks and distribute the work in the community. If the removal of Orc v1 is part of the plan, we should start convergence soon.
* Communicate/discuss the current state (haves and wants) regularly and transparently.
* Get more people to participate actively.


[1] https://github.com/llvm/llvm-project/commit/93de2a12
[2] http://releases.llvm.org/3.8.0/docs/ReleaseNotes.html#non-comprehensive-list-of-changes-in-this-release
[3] http://lists.llvm.org/pipermail/llvm-dev/2016-March/097767.html
[4] https://reviews.llvm.org/D61611

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
https://flowcrypt.com/pub/stefan....@gmail.com

--

Christian Schafmeister

Professor, Chemistry Department

Temple University

[Stefan Gränitz via llvm-dev]

On 5/17/19 9:46 PM, Christian Schafmeister wrote:

I'm very excited about the work Lang has been doing

Yes, I completely agree! And I am sure everyone does. Without his work Orc wouldn't exist and we wouldn't be anywhere close to it.

-- 
https://flowcrypt.com/pub/stefan....@gmail.com

[Lang Hames via llvm-dev]

Hi Alex,

1. Is there a migration guide I can use to update my code to the new version?

There is no guide yet. It sounds like there is plenty of interest in creating one. I’m also going to try to post a draft of the ORCv2 design document we discussed later tonight.

For what it is worth, I expect migration to be fairly straightforward for most clients. Each of the legacy layers that is being deprecated has an ORCv2 counterpart that can be substituted in a fairly mechanical way (with the exception of the LazyEmittingLayer that provided MCJIT-style laziness, “don’t compile until first lookup”, which is the default behavior in ORCv2).

MCJIT clients, or clients with simple use cases may find LLJIT useful. This is an off the shelf ORC JIT class with functionality similar to MCJIT. Some utilities (e.g. EventListeners) have not been hooked up yet, but I think it would be reasonable to get these hooked up before 9.0 branches.

2. Is there any development plan for this part of LLVM? So far I have feeling that it's a closed source development.

It is definitely not closed source. There is no part of ORCv2 that has not been committed to the public tree, except for the small amount of code currently on my development branch.

I think it’s fair to say that the design has not been well documented or communicated (except in code and commit messages). Given the demand though (and exciting prospect of more contributors) it sounds like it’s time to put some documentation together. The ORCv2 design doc can serve as a starting point, and the tutorials that Praveen plans to update will be a *huge* help. Patches and support are most welcome. :)

3. Is there some communication channels I am missing to follow? I follow dev&commits mailing lists and present on IRC once in a while, but I somehow missed the message about the Orc v1 removal.

No — you are not missing anything. I think the plan to deprecate has been mentioned on list before but only in passing (and thinking about it, it may even have been on llvm-commits rather than llvm-dev). I plan to add deprecation attributes to the legacy classes on trunk so that clients who use 9.0 receive warnings. If we find that clients have trouble migrating (which I don’t think we will) then we can probably support the legacy layers for another release, but I would like to avoid this if possible.

Cheers,

Lang.

Sent from my iPad

[Stefan Gränitz via llvm-dev]

On 5/17/19 9:46 PM, Christian Schafmeister wrote:

Recently, I switched over to using the new API - works great! 

FYI the Orc v2 JIT is here:
https://github.com/clasp-developers/clasp/commit/f66d7260#diff-6a3b65e229a66395da951fc9ee989ef0R4269

I'm excited to hear that there is a fix for lldb debugging of jitted code coming (thanks Stefan!).

Well, it's a start. (One can always fall back to GDB :b)
Updated the bug report, with a shot summary of what has been done and what is necessary next: https://bugs.llvm.org/show_bug.cgi?id=36209#c2

On 5/17/19 9:46 PM, Christian Schafmeister wrote:

-- 
https://flowcrypt.com/pub/stefan....@gmail.com

[Alex Denisov via llvm-dev]

Hello everyone,

Praveen,

> You can also take a look at "Updating ORC for Concurrency" talk by lang hames, the talk explains about the new APIs.

It's a good reference, but it is not sufficient as communication channel, imho.

> For documentation kaleidoscope, I don't think the updated version is available yet.

It is very often outdated, so I developed (not on purpose) a mental model of not relying on it.

Lang,

> There is no guide yet. It sounds like there is plenty of interest in creating one. I’m also going to try to post a draft of the ORCv2 design document we discussed later tonight.

I'll try to migrate my code to the v2 API and describe the process, but please don't take my words as a promise :-D

> It is definitely not closed source.

After re-reading my statement I realized that it was too harsh, sorry about that. I rather meant that I was only able to get information post factum, which reminded some of our hardware vendors :)

> I plan to add deprecation attributes to the legacy classes on trunk so that clients who use 9.0 receive warnings.

That's a very good idea. I think I understand your motivation to force everyone to use the new APIs, but I also think it makes sense to make the migration process a bit more smooth.


Stefan,

Thanks for the summary and for bringing more people into the discussion.

Thanks a lot for your contributions, folks!

Cheers,
Alex.

[Lang Hames via llvm-dev]

Hi Alex,

I'll try to migrate my code to the v2 API and describe the process, but please don't take my words as a promise :-D

No worries. Any help will be greatly appreciated!

After re-reading my statement I realized that it was too harsh, sorry about that. I rather meant that I was only able to get information post factum, which reminded some of our hardware vendors :)

 No worries. Getting concurrency into ORC (which is the main aim of ORCv2, vs ORCv1) has involved a lot of trial and error, and corresponding churn in the APIs, and that has made documentation challenging. This isn't intended to be a permanent state of affairs though, and the more the APIs settle down, the easier and more rewarding documentation will be (both to write and to use).

> I plan to add deprecation attributes to the legacy classes on trunk so that clients who use 9.0 receive warnings.
That's a very good idea. I think I understand your motivation to force everyone to use the new APIs, but I also think it makes sense to make the migration process a bit more smooth.

I have filed http://llvm.org/PR41986 if anyone wants to jump on it. :)

-- Lang. 

[Stefan Gränitz via llvm-dev]

Hi Praveen

> Correction : Kaleidoscope chapter 1 & 2 are up-to-date. But chapter
> 3..5 are not.

Where do you got the info from? Do you know what exactly is missing/broken?

Maybe we summarize in a ticket and try to get it done before the next
release.
Currently we only have: https://bugs.llvm.org/show_bug.cgi?id=41595

Cheers
Stefan

[Frank Tetzel via llvm-dev]

> > Correction : Kaleidoscope chapter 1 & 2 are up-to-date. But chapter
> > 3..5 are not.
>
> Where do you got the info from? Do you know what exactly is
> missing/broken?

It is mentioned on the tutorial page as a warning at the top:
http://llvm.org/docs/tutorial/BuildingAJIT1.html

> Maybe we summarize in a ticket and try to get it done before the next
> release.
> Currently we only have: https://bugs.llvm.org/show_bug.cgi?id=41595

[Stefan Gränitz via llvm-dev]

Oh I see, thanks. Haven't been looking there as I considered it two
different tutorials. Ok, one builds on the other, so the distinction may
be artificial..

Kaleidoscope: http://llvm.org/docs/tutorial/LangImpl01.html -- all
up-to-date?
BuildingAJIT: http://llvm.org/docs/tutorial/BuildingAJIT1.html -- update
chapters 3-5 is todo?

On 5/24/19 2:59 PM, Frank Tetzel wrote:
>>> Correction : Kaleidoscope chapter 1 & 2 are up-to-date. But chapter
>>> 3..5 are not.
>> Where do you got the info from? Do you know what exactly is
>> missing/broken?
> It is mentioned on the tutorial page as a warning at the top:
> http://llvm.org/docs/tutorial/BuildingAJIT1.html
>
>
>> Maybe we summarize in a ticket and try to get it done before the next
>> release.
>> Currently we only have: https://bugs.llvm.org/show_bug.cgi?id=41595

--
https://flowcrypt.com/pub/stefan....@gmail.com