[llvm-dev] OrcV1 removal

Lang Hames via llvm-dev
Mon, 07 Sep 2020 20:55:44 -0000

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/f58f5467/attachment.html>