Hi All, 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! Kind Regards, Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200906/0d144753/attachment.html>
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
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>