[llvm-dev] Orc JIT v1 Deprecation

Sat May 18 07:33:22 PDT 2019

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:

> 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190518/32ec8e5b/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/20190518/32ec8e5b/attachment.sig>