[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

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/20200907/6a6d5be3/attachment.html>