[llvm-dev] Orc JIT v1 Deprecation

Stefan Gränitz via llvm-dev llvm-dev at lists.llvm.org
Fri May 17 14:25:00 PDT 2019

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.

On 5/17/19 9:46 PM, Christian Schafmeister wrote:
> 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.graenitz at gmail.com <mailto:stefan.graenitz at 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
>     On 5/13/19 10:22 AM, Alex Denisov via llvm-dev wrote:
>>     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.
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     -- 
>     https://flowcrypt.com/pub/stefan.graenitz@gmail.com
> -- 
> Christian Schafmeister
> Professor, Chemistry Department
> Temple University


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190517/f5d71be7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190517/f5d71be7/attachment.sig>

More information about the llvm-dev mailing list