Christian Schafmeister via llvm-dev
2019-May-17 19:46 UTC
[llvm-dev] Orc JIT v1 Deprecation
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> 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 listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- https://flowcrypt.com/pub/stefan.graenitz at 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/3a2c7a30/attachment.html>
On 5/17/19 9:46 PM, Christian Schafmeister wrote:> I'm very excited about the work Lang has been doingYes, 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 at gmail.com > > > > -- > Christian Schafmeister > Professor, Chemistry Department > Temple University-- https://flowcrypt.com/pub/stefan.graenitz at gmail.com -------------- 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>
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 at gmail.com > > > > -- > Christian Schafmeister > Professor, Chemistry Department > Temple University-- https://flowcrypt.com/pub/stefan.graenitz at 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>