<div dir="ltr"><div dir="ltr">Hi Andres,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Postgres uses removable code support and Orcv1. I does make me quite<br>worried to see a phase where there'll be no viable way of using both in<br>llvm.  Why isn't the right answer here to at lest develop the<br>replacement as a set of patches / as a branch that then can be merged as<br>a whole / shortly after each other, rather than just starting to develop<br>a replacement after the removal.</blockquote></div><div><br></div><div>That sounds good to me. I'll create a branch called 'orcv1-removal' for this shortly.</div><div><br></div><div>Regards,</div><div>Lang. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 7, 2020 at 12:53 PM Andres Freund <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2020-09-06 23:16:00 -0700, Lang Hames wrote:<br>
> The time has finally come to remove OrcV1. I expect to remove it some time<br>
> after the 14th of September. This will remove all the legacy layers, legacy<br>
> utilities, the old Orc C bindings, and OrcMCJITReplacement. ExecutionEngine<br>
> and MCJIT will *not* be affected by this.<br>
> <br>
> I had hoped to have removable code enabled before deleting OrcV1, but it<br>
> turns out that implementing removable code in OrcV2 without simultaneously<br>
> breaking it in OrcV1 is difficult. Instead my plan is to delete OrcV1 and<br>
> implement removable code in OrcV2 as quickly as possible. I think this is<br>
> the fastest path to where we want to be.<br>
> <br>
> If you're on llvm master, still using the legacy layers, and you *don't*<br>
> need removable code support, then I would encourage you to switch over as<br>
> soon as you're able. If you *do* need removable code support then you may<br>
> have to wait a few weeks for it to land.<br>
> <br>
> If you have any questions about the removal please let me know!<br>
<br>
Postgres uses removable code support and Orcv1. I does make me quite<br>
worried to see a phase where there'll be no viable way of using both in<br>
llvm.  Why isn't the right answer here to at lest develop the<br>
replacement as a set of patches / as a branch that then can be merged as<br>
a whole / shortly after each other, rather than just starting to develop<br>
a replacement after the removal.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>