Hi All, I've updated the orcv1 removal branch ( https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial patch for removable code. If anyone wants to follow along with the development or share thoughts on the design you're very welcome to. I'll be adding tests and comments this week, but for anyone who wants to take an early look the main elements are defined in Core.h: *ResourceTracker* -- Your handle to remove code from a JITDylib. Also allows tracking to be merged onto another tracker (reducing the administrative overhead required for tracking). *ResourceKey* -- An opaque key associated with each tracker. *ResourceManager* -- A listener interface to be notified when resources associated with a given key should be removed. Each JITDylib will have a default tracker (accessible via JITDylib::getDefaultResourceTracker), and allow creation of new trackers (via JITDylib::createResourceTracker). When adding a MaterializationUnit to a JITDylib (with JITDylib::define, or a Layer's add method) you can optionally specify a tracker to associate with that unit. If no tracker is specified the default tracker for the target JITDylib will be used. A single tracker can be associated with multiple units the remove and transferTo operations (see below) will apply to all associated units. You can call ResourceTracker::remove at any time to remove all symbols and resources associated with a tracker. Any active compiles associated with the tracker will receive an error when they try to update the JIT state via their MaterializationResponsibility, and will not be able to associate resources with the tracker's associated ResourceKey. You can call ResourceTracker::transferTo at any time. This will transfer tracking of all associated symbols and resources to the destination tracker. Any active compiles associated with the tracker will be reassociated with the destination tracker, and all future resources will be associated with the destination tracker. Merging trackers can reduce administrative overhead, especially when merging onto the default tracker for the JITDylib, which has a more compact representation for ownership of symbols. Calling JITDylib::clear() will call remove on all trackers created by the JITDylib (including the default one). ResourceTrackers have shared ownership, but the ExecutionSession and JITDylib do not retain ownership (except for the default tracker). If you release all pointers to a tracker its resources will be automatically transferred (via transferTo) to the default tracker for the JITDylib. ResourceManagers (usually Layers) can call MaterializationResponsibility::withKeyDo(...) to associate a ResourceKey with JIT resources (e.g. allocated memory) in a way that is safe even if remove/transferTo is called on the same tracker from other threads. A note for those of you who've been following along with the ORC Weekly emails: I had previously convinced myself that we'd only be able to do JITDylib at a time removal. This scheme is more flexible than that -- I'm hoping it ends up being a nice compromise. If you ignore tracking in your API it is effectively JITDylib-at-a-time (through the default tracker), but if you do want to do fine grained removal you can, you just assume responsibility for properly handling dependencies (i.e. not removing anything that the JIT program might still be using). I'll be re-hashing this in more detail in this week's ORC Weekly update, hopefully with examples and cleaner code. Regards, Lang. On Mon, Sep 7, 2020 at 9:26 PM Lang Hames <lhames at gmail.com> wrote:> Hi Andres, > > The orcv1-removal branch is now available (with OrcV1 removed) at > https://github.com/lhames/llvm-project/tree/orcv1-removal. I'll get to > work on the removable code feature -- hopefully I'll have something for you > to test soon. > > Regards, > Lang. > > On Mon, Sep 7, 2020 at 1:55 PM Lang Hames <lhames at gmail.com> wrote: > >> Hi Andres, >> >> Postgres uses removable code support and Orcv1. I does make me quite >>> worried to see a phase where there'll be no viable way of using both in >>> llvm. Why isn't the right answer here to at lest develop the >>> replacement as a set of patches / as a branch that then can be merged as >>> a whole / shortly after each other, rather than just starting to develop >>> a replacement after the removal. >> >> >> That sounds good to me. I'll create a branch called 'orcv1-removal' for >> this shortly. >> >> Regards, >> Lang. >> >> On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <andres at anarazel.de> wrote: >> >>> Hi, >>> >>> On 2020-09-06 23:16:00 -0700, Lang Hames wrote: >>> > The time has finally come to remove OrcV1. I expect to remove it some >>> time >>> > after the 14th of September. This will remove all the legacy layers, >>> legacy >>> > utilities, the old Orc C bindings, and OrcMCJITReplacement. >>> ExecutionEngine >>> > and MCJIT will *not* be affected by this. >>> > >>> > I had hoped to have removable code enabled before deleting OrcV1, but >>> it >>> > turns out that implementing removable code in OrcV2 without >>> simultaneously >>> > breaking it in OrcV1 is difficult. Instead my plan is to delete OrcV1 >>> and >>> > implement removable code in OrcV2 as quickly as possible. I think this >>> is >>> > the fastest path to where we want to be. >>> > >>> > If you're on llvm master, still using the legacy layers, and you >>> *don't* >>> > need removable code support, then I would encourage you to switch over >>> as >>> > soon as you're able. If you *do* need removable code support then you >>> may >>> > have to wait a few weeks for it to land. >>> > >>> > If you have any questions about the removal please let me know! >>> >>> Postgres uses removable code support and Orcv1. I does make me quite >>> worried to see a phase where there'll be no viable way of using both in >>> llvm. Why isn't the right answer here to at lest develop the >>> replacement as a set of patches / as a branch that then can be merged as >>> a whole / shortly after each other, rather than just starting to develop >>> a replacement after the removal. >>> >>> Greetings, >>> >>> Andres Freund >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/ba038d30/attachment.html>
Hi, On 2020-09-16 11:52:11 -0700, Lang Hames wrote:> I've updated the orcv1 removal branch ( > https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial > patch for removable code. If anyone wants to follow along with the > development or share thoughts on the design you're very welcome to.Cool!I assume this works on "non-native" jitlink platforms as well? Or just mach? Looks like there's not yet a C API yet - not a problem, just checking. Currently it looks like only the main jit dylib is exposed via C, right? We can't really do the same for resource trackers, if I understand this correctly. Sketching out what I'd need to do to test postgres, so I don't waste time going in the wrong direction: 1) Add API for management (create, destroy) a non-default resource tracker (i.e. JITDylib::createResourceTracker) 3) Add JITDylib::clear() wrapper 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument (defaulting to NULL for the default resource tracker?) to specify the resource tracker 4) LLJIT would need to grow the underlying support methods Does that sound roughly right? Independent questions about the current C API: - Would be nice to document [non-]mangling behaviour of LLVMOrcLLJITLookup() - Do I understand correctly that there's no way to keep a memory buffer with an object file alive after adding it with LLVMOrcLLJITAddObjectFile()? But that it's fine to create multiple buffers for the same memory with LLVMCreateMemoryBufferWithMemoryRange()?> You can call ResourceTracker::remove at any time to remove all symbols and > resources associated with a tracker. Any active compiles associated with > the tracker will receive an error when they try to update the JIT state via > their MaterializationResponsibility, and will not be able to associate > resources with the tracker's associated ResourceKey. > > You can call ResourceTracker::transferTo at any time. This will transfer > tracking of all associated symbols and resources to the destination > tracker. Any active compiles associated with the tracker will be > reassociated with the destination tracker, and all future resources will be > associated with the destination tracker. Merging trackers can reduce > administrative overhead, especially when merging onto the default tracker > for the JITDylib, which has a more compact representation for ownership of > symbols. > > Calling JITDylib::clear() will call remove on all trackers created by the > JITDylib (including the default one). > > ResourceTrackers have shared ownership, but the ExecutionSession and > JITDylib do not retain ownership (except for the default tracker). If you > release all pointers to a tracker its resources will be automatically > transferred (via transferTo) to the default tracker for the JITDylib.I assume it is not legal to use the same resource tracker with two different JITDylib's? Greetings, Andres Freund
Hi Andres, Cool!I assume this works on "non-native" jitlink platforms as well? Or> just mach?This framework is totally materializer agnostic -- It works for ObjectLinkingLayer (JITLink), RTDyldObjectLinkingLayer (RuntimeDyld), and even materializers that aren't emitted via a linker (e.g. stubs and callbacks). Looks like there's not yet a C API yet - not a problem, just checking. No C API yet, but I'll add one as soon as the C++ API settles down (probably in a week or so). Currently it looks like only the main jit dylib is exposed via C, right? We can't really do the same for resource trackers, if I understand this correctly. Sketching out what I'd need to do to test postgres, so I don't waste time going in the wrong direction: Currently it looks like only the main jit dylib is exposed via C, right? That was true -- I just hadn't gotten around to it. Your question seems as good an excuse as any to take a minute out and do that, so I've added them in 9a0d1b66730. :) We can't really do the same for resource trackers, if I understand this> correctly. Sketching out what I'd need to do to test postgres, so I > don't waste time going in the wrong direction:1) Add API for management (create, destroy) a non-default resource tracker> (i.e. JITDylib::createResourceTracker) > 3) Add JITDylib::clear() wrapper > 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument > (defaulting to NULL for the default resource tracker?) to specify the > resource tracker > 4) LLJIT would need to grow the underlying support methodsThat's all spot-on. It should not require much code either: Both the C API and LLJIT itself are pretty thin wrappers around the core APIs -- each of these wrappers should just be a few lines. I assume it is not legal to use the same resource tracker with two> different JITDylib's?That's correct -- ResourceTrackers are bound to the JITDylib they're created from. They should assert if you use them with the wrong JITDylib, though I'm not sure how good the coverage on those asserts are yet. I think this system could be generalized to enable cross-dylib tracking at the cost of a few dozen extra bytes per tracker. Do you have a use-case for this? Regards, Lang. On Wed, Sep 16, 2020 at 12:48 PM Andres Freund <andres at anarazel.de> wrote:> Hi, > > On 2020-09-16 11:52:11 -0700, Lang Hames wrote: > > I've updated the orcv1 removal branch ( > > https://github.com/lhames/llvm-project/tree/orcv1-removal) with an > initial > > patch for removable code. If anyone wants to follow along with the > > development or share thoughts on the design you're very welcome to. > > Cool!I assume this works on "non-native" jitlink platforms as well? Or > just mach? > > Looks like there's not yet a C API yet - not a problem, just checking. > > Currently it looks like only the main jit dylib is exposed via C, right? > We can't really do the same for resource trackers, if I understand this > correctly. Sketching out what I'd need to do to test postgres, so I > don't waste time going in the wrong direction: > > 1) Add API for management (create, destroy) a non-default resource tracker > (i.e. JITDylib::createResourceTracker) > 3) Add JITDylib::clear() wrapper > 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument > (defaulting to NULL for the default resource tracker?) to specify the > resource tracker > 4) LLJIT would need to grow the underlying support methods > > Does that sound roughly right? > > Independent questions about the current C API: > - Would be nice to document [non-]mangling behaviour of > LLVMOrcLLJITLookup() > - Do I understand correctly that there's no way to keep a memory buffer > with an object file alive after adding it with > LLVMOrcLLJITAddObjectFile()? But that it's fine to create multiple > buffers for the same memory with LLVMCreateMemoryBufferWithMemoryRange()? > > > > You can call ResourceTracker::remove at any time to remove all symbols > and > > resources associated with a tracker. Any active compiles associated with > > the tracker will receive an error when they try to update the JIT state > via > > their MaterializationResponsibility, and will not be able to associate > > resources with the tracker's associated ResourceKey. > > > > You can call ResourceTracker::transferTo at any time. This will transfer > > tracking of all associated symbols and resources to the destination > > tracker. Any active compiles associated with the tracker will be > > reassociated with the destination tracker, and all future resources will > be > > associated with the destination tracker. Merging trackers can reduce > > administrative overhead, especially when merging onto the default tracker > > for the JITDylib, which has a more compact representation for ownership > of > > symbols. > > > > Calling JITDylib::clear() will call remove on all trackers created by the > > JITDylib (including the default one). > > > > ResourceTrackers have shared ownership, but the ExecutionSession and > > JITDylib do not retain ownership (except for the default tracker). If you > > release all pointers to a tracker its resources will be automatically > > transferred (via transferTo) to the default tracker for the JITDylib. > > I assume it is not legal to use the same resource tracker with two > different JITDylib's? > > > Greetings, > > Andres Freund >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/802f2e7a/attachment.html>
Hi All, I'll be re-hashing this in more detail in this week's ORC Weekly update,> hopefully with examples and cleaner code.Time got away from me last week unfortunately. I'm still landing unit tests and cleanups on the OrcV1 removal branch, but I hope to put out an ORC Weekly update on Friday covering the latest developments. In the meantime you can find some very basic example usage in llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp ( https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp ). -- Lang. On Wed, Sep 16, 2020 at 11:52 AM Lang Hames <lhames at gmail.com> wrote:> Hi All, > > I've updated the orcv1 removal branch ( > https://github.com/lhames/llvm-project/tree/orcv1-removal) with an > initial patch for removable code. If anyone wants to follow along with the > development or share thoughts on the design you're very welcome to. > > I'll be adding tests and comments this week, but for anyone who wants to > take an early look the main elements are defined in Core.h: > > *ResourceTracker* -- Your handle to remove code from a JITDylib. Also > allows tracking to be merged onto another tracker (reducing the > administrative overhead required for tracking). > *ResourceKey* -- An opaque key associated with each tracker. > *ResourceManager* -- A listener interface to be notified when resources > associated with a given key should be removed. > > Each JITDylib will have a default tracker (accessible via > JITDylib::getDefaultResourceTracker), and allow creation of new trackers > (via JITDylib::createResourceTracker). When adding a MaterializationUnit to > a JITDylib (with JITDylib::define, or a Layer's add method) you can > optionally specify a tracker to associate with that unit. If no tracker is > specified the default tracker for the target JITDylib will be used. A > single tracker can be associated with multiple units the remove and > transferTo operations (see below) will apply to all associated units. > > You can call ResourceTracker::remove at any time to remove all symbols and > resources associated with a tracker. Any active compiles associated with > the tracker will receive an error when they try to update the JIT state via > their MaterializationResponsibility, and will not be able to associate > resources with the tracker's associated ResourceKey. > > You can call ResourceTracker::transferTo at any time. This will transfer > tracking of all associated symbols and resources to the destination > tracker. Any active compiles associated with the tracker will be > reassociated with the destination tracker, and all future resources will be > associated with the destination tracker. Merging trackers can reduce > administrative overhead, especially when merging onto the default tracker > for the JITDylib, which has a more compact representation for ownership of > symbols. > > Calling JITDylib::clear() will call remove on all trackers created by the > JITDylib (including the default one). > > ResourceTrackers have shared ownership, but the ExecutionSession and > JITDylib do not retain ownership (except for the default tracker). If you > release all pointers to a tracker its resources will be automatically > transferred (via transferTo) to the default tracker for the JITDylib. > > ResourceManagers (usually Layers) can call > MaterializationResponsibility::withKeyDo(...) to associate a ResourceKey > with JIT resources (e.g. allocated memory) in a way that is safe even if > remove/transferTo is called on the same tracker from other threads. > > A note for those of you who've been following along with the ORC Weekly > emails: I had previously convinced myself that we'd only be able to do > JITDylib at a time removal. This scheme is more flexible than that -- I'm > hoping it ends up being a nice compromise. If you ignore tracking in your > API it is effectively JITDylib-at-a-time (through the default tracker), but > if you do want to do fine grained removal you can, you just assume > responsibility for properly handling dependencies (i.e. not removing > anything that the JIT program might still be using). > > I'll be re-hashing this in more detail in this week's ORC Weekly update, > hopefully with examples and cleaner code. > > Regards, > Lang. > > On Mon, Sep 7, 2020 at 9:26 PM Lang Hames <lhames at gmail.com> wrote: > >> Hi Andres, >> >> The orcv1-removal branch is now available (with OrcV1 removed) at >> https://github.com/lhames/llvm-project/tree/orcv1-removal. I'll get to >> work on the removable code feature -- hopefully I'll have something for you >> to test soon. >> >> Regards, >> Lang. >> >> On Mon, Sep 7, 2020 at 1:55 PM Lang Hames <lhames at gmail.com> wrote: >> >>> Hi Andres, >>> >>> Postgres uses removable code support and Orcv1. I does make me quite >>>> worried to see a phase where there'll be no viable way of using both in >>>> llvm. Why isn't the right answer here to at lest develop the >>>> replacement as a set of patches / as a branch that then can be merged as >>>> a whole / shortly after each other, rather than just starting to develop >>>> a replacement after the removal. >>> >>> >>> That sounds good to me. I'll create a branch called 'orcv1-removal' for >>> this shortly. >>> >>> Regards, >>> Lang. >>> >>> On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <andres at anarazel.de> >>> wrote: >>> >>>> Hi, >>>> >>>> On 2020-09-06 23:16:00 -0700, Lang Hames wrote: >>>> > The time has finally come to remove OrcV1. I expect to remove it some >>>> time >>>> > after the 14th of September. This will remove all the legacy layers, >>>> legacy >>>> > utilities, the old Orc C bindings, and OrcMCJITReplacement. >>>> ExecutionEngine >>>> > and MCJIT will *not* be affected by this. >>>> > >>>> > I had hoped to have removable code enabled before deleting OrcV1, but >>>> it >>>> > turns out that implementing removable code in OrcV2 without >>>> simultaneously >>>> > breaking it in OrcV1 is difficult. Instead my plan is to delete OrcV1 >>>> and >>>> > implement removable code in OrcV2 as quickly as possible. I think >>>> this is >>>> > the fastest path to where we want to be. >>>> > >>>> > If you're on llvm master, still using the legacy layers, and you >>>> *don't* >>>> > need removable code support, then I would encourage you to switch >>>> over as >>>> > soon as you're able. If you *do* need removable code support then you >>>> may >>>> > have to wait a few weeks for it to land. >>>> > >>>> > If you have any questions about the removal please let me know! >>>> >>>> Postgres uses removable code support and Orcv1. I does make me quite >>>> worried to see a phase where there'll be no viable way of using both in >>>> llvm. Why isn't the right answer here to at lest develop the >>>> replacement as a set of patches / as a branch that then can be merged as >>>> a whole / shortly after each other, rather than just starting to develop >>>> a replacement after the removal. >>>> >>>> Greetings, >>>> >>>> Andres Freund >>>> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/1f273b33/attachment.html>
Hi All, The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline. If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the work in the mainline early next week. -- Lang. On Mon, Sep 21, 2020 at 9:51 PM Lang Hames <lhames at gmail.com> wrote:> Hi All, > > I'll be re-hashing this in more detail in this week's ORC Weekly update, >> hopefully with examples and cleaner code. > > > Time got away from me last week unfortunately. I'm still landing unit > tests and cleanups on the OrcV1 removal branch, but I hope to put out an > ORC Weekly update on Friday covering the latest developments. In the > meantime you can find some very basic example usage in > llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp ( > https://github.com/lhames/llvm-project/blob/orcv1-removal/llvm/unittests/ExecutionEngine/Orc/ResourceTrackerTest.cpp > ). > > -- Lang. > > On Wed, Sep 16, 2020 at 11:52 AM Lang Hames <lhames at gmail.com> wrote: > >> Hi All, >> >> I've updated the orcv1 removal branch ( >> https://github.com/lhames/llvm-project/tree/orcv1-removal) with an >> initial patch for removable code. If anyone wants to follow along with the >> development or share thoughts on the design you're very welcome to. >> >> I'll be adding tests and comments this week, but for anyone who wants to >> take an early look the main elements are defined in Core.h: >> >> *ResourceTracker* -- Your handle to remove code from a JITDylib. Also >> allows tracking to be merged onto another tracker (reducing the >> administrative overhead required for tracking). >> *ResourceKey* -- An opaque key associated with each tracker. >> *ResourceManager* -- A listener interface to be notified when resources >> associated with a given key should be removed. >> >> Each JITDylib will have a default tracker (accessible via >> JITDylib::getDefaultResourceTracker), and allow creation of new trackers >> (via JITDylib::createResourceTracker). When adding a MaterializationUnit to >> a JITDylib (with JITDylib::define, or a Layer's add method) you can >> optionally specify a tracker to associate with that unit. If no tracker is >> specified the default tracker for the target JITDylib will be used. A >> single tracker can be associated with multiple units the remove and >> transferTo operations (see below) will apply to all associated units. >> >> You can call ResourceTracker::remove at any time to remove all symbols >> and resources associated with a tracker. Any active compiles associated >> with the tracker will receive an error when they try to update the JIT >> state via their MaterializationResponsibility, and will not be able to >> associate resources with the tracker's associated ResourceKey. >> >> You can call ResourceTracker::transferTo at any time. This will transfer >> tracking of all associated symbols and resources to the destination >> tracker. Any active compiles associated with the tracker will be >> reassociated with the destination tracker, and all future resources will be >> associated with the destination tracker. Merging trackers can reduce >> administrative overhead, especially when merging onto the default tracker >> for the JITDylib, which has a more compact representation for ownership of >> symbols. >> >> Calling JITDylib::clear() will call remove on all trackers created by the >> JITDylib (including the default one). >> >> ResourceTrackers have shared ownership, but the ExecutionSession and >> JITDylib do not retain ownership (except for the default tracker). If you >> release all pointers to a tracker its resources will be automatically >> transferred (via transferTo) to the default tracker for the JITDylib. >> >> ResourceManagers (usually Layers) can call >> MaterializationResponsibility::withKeyDo(...) to associate a ResourceKey >> with JIT resources (e.g. allocated memory) in a way that is safe even if >> remove/transferTo is called on the same tracker from other threads. >> >> A note for those of you who've been following along with the ORC Weekly >> emails: I had previously convinced myself that we'd only be able to do >> JITDylib at a time removal. This scheme is more flexible than that -- I'm >> hoping it ends up being a nice compromise. If you ignore tracking in your >> API it is effectively JITDylib-at-a-time (through the default tracker), but >> if you do want to do fine grained removal you can, you just assume >> responsibility for properly handling dependencies (i.e. not removing >> anything that the JIT program might still be using). >> >> I'll be re-hashing this in more detail in this week's ORC Weekly update, >> hopefully with examples and cleaner code. >> >> Regards, >> Lang. >> >> On Mon, Sep 7, 2020 at 9:26 PM Lang Hames <lhames at gmail.com> wrote: >> >>> Hi Andres, >>> >>> The orcv1-removal branch is now available (with OrcV1 removed) at >>> https://github.com/lhames/llvm-project/tree/orcv1-removal. I'll get to >>> work on the removable code feature -- hopefully I'll have something for you >>> to test soon. >>> >>> Regards, >>> Lang. >>> >>> On Mon, Sep 7, 2020 at 1:55 PM Lang Hames <lhames at gmail.com> wrote: >>> >>>> Hi Andres, >>>> >>>> Postgres uses removable code support and Orcv1. I does make me quite >>>>> worried to see a phase where there'll be no viable way of using both in >>>>> llvm. Why isn't the right answer here to at lest develop the >>>>> replacement as a set of patches / as a branch that then can be merged >>>>> as >>>>> a whole / shortly after each other, rather than just starting to >>>>> develop >>>>> a replacement after the removal. >>>> >>>> >>>> That sounds good to me. I'll create a branch called 'orcv1-removal' for >>>> this shortly. >>>> >>>> Regards, >>>> Lang. >>>> >>>> On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <andres at anarazel.de> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On 2020-09-06 23:16:00 -0700, Lang Hames wrote: >>>>> > The time has finally come to remove OrcV1. I expect to remove it >>>>> some time >>>>> > after the 14th of September. This will remove all the legacy layers, >>>>> legacy >>>>> > utilities, the old Orc C bindings, and OrcMCJITReplacement. >>>>> ExecutionEngine >>>>> > and MCJIT will *not* be affected by this. >>>>> > >>>>> > I had hoped to have removable code enabled before deleting OrcV1, >>>>> but it >>>>> > turns out that implementing removable code in OrcV2 without >>>>> simultaneously >>>>> > breaking it in OrcV1 is difficult. Instead my plan is to delete >>>>> OrcV1 and >>>>> > implement removable code in OrcV2 as quickly as possible. I think >>>>> this is >>>>> > the fastest path to where we want to be. >>>>> > >>>>> > If you're on llvm master, still using the legacy layers, and you >>>>> *don't* >>>>> > need removable code support, then I would encourage you to switch >>>>> over as >>>>> > soon as you're able. If you *do* need removable code support then >>>>> you may >>>>> > have to wait a few weeks for it to land. >>>>> > >>>>> > If you have any questions about the removal please let me know! >>>>> >>>>> Postgres uses removable code support and Orcv1. I does make me quite >>>>> worried to see a phase where there'll be no viable way of using both in >>>>> llvm. Why isn't the right answer here to at lest develop the >>>>> replacement as a set of patches / as a branch that then can be merged >>>>> as >>>>> a whole / shortly after each other, rather than just starting to >>>>> develop >>>>> a replacement after the removal. >>>>> >>>>> Greetings, >>>>> >>>>> Andres Freund >>>>> >>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200924/e6380438/attachment.html>