search for: orcv1

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...

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 i...

Hi All, Everything is landing all at once, just not in the mainline... yet. As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html: OrcV1 will be removed very soon. I have posted a branch with the removal, "orcv1-removal", in my llvm fork at https://github.com/lhames/llvm-project. In addition to removing OrcV1, the orcv1-removal branch also contains a prototype of the removable code feature. I'm going to discuss this a...

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...

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. Other...

...efinition discovery to take an > arbitrarily long time without blocking forward progress on other JIT work. Sounds useful. > I'm guessing your objective for now is to minimize churn, right? If that's > the case I'll focus on moving to the continuation passing API on the > orcv1-removal branch before I update the C API. Yes, I do prefer less churn. It's not a deal breaker, but I try to keep PG compiling against trunk LLVM, and there's multiple stable branches - so it's somewhat noisy to do that repeatedly (including syncing up that all the LLVM trunk test mach...

...people find the updates valuable I will make an effort to write at least something. Questions and comments are most welcome (both on the format, and on the content). Since this is the first update, I have also added some highlights from last year, and the plan for 2020. Highlights from 2019: (1) ORCv1 was officially deprecated in LLVM 9. I have left it in for the LLVM 10 branch, but plan to remove it from master in the coming weeks. All development effort is now focused on ORCv2. If you are an ORCv1 client, now's the time to switch over. If you need help please ask on the llvm-dev mailing li...

Hi, On 2020-09-29 13:58:35 -0700, Lang Hames wrote: > > Have the basics working. Should I open a PR to your branch for what I > > got so far? > Sounds good to me. Done, https://github.com/lhames/llvm-project/pull/2 . > The first is to expose more of symbol resolution. Postgres can be > > extended via dynamically loaded libraries, and we need to be careful to > >

...ok like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I don't have time to implement it just yet, but I would be very happy to provide support and review patches if anyone else wants to give it a shot. What's the capability level of ORCv2 on RuntimeDyld compared to ORCv1? > Are there features supported in v1 that are only available on JITLink > supported platforms? At a high level, ORCv2's design allows for basically the same features as ORCv1, plus concurrent compilation. There are still a number of APIs that haven't been hooked up or implemented t...

Hi, On 2020-09-30 19:00:45 -0700, Lang Hames wrote: > Ok -- I'll make getting the new lookup API working a priority then. Cool. > > I see a memory leak with OrcV2 that I didn't see with V1. I'm not yet > > sure where exactly they're coming from. Possible that I'm just missing a > > step somewhere. Or something around the removable code support

...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 work...

...s. Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org> 于2020年1月17日周五 下午11:38写道： > Thank you for creating weekly updates, they will be quite useful, since > previously ORC development seemed rather opaque. > > One thing that will be useful (and was done to some extent with ORCv1) is > to expose ORCv2's API via C-compatible bindings such that code from > languages other than C++ (Rust for me) can effectively use it, including > things such as the equivalent of -march=native and introspection such that > the supported SIMD widths can be detected. I'm plan...

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

Hi, On 2020-09-25 16:38:41 -0700, Andres Freund via llvm-dev wrote: > On 2020-09-24 16:34:30 -0700, Lang Hames wrote: > > 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. > > I'm trying to get it to work with postgres. Unfortunately this week was a bit less > productive than I had hoped... Hope to get there Mon...

Hi folks, I'm working on migrating a JIT compiler from the old ORCv1 JIT APIs to the newer ORCv2 ones and am having some trouble getting the code from chapter 1 of the "Building a JIT" [1] tutorial working properly. I have previously walked through the "My First Langauge" [2] tutorial and that went smoothly using the provided JIT class, but using...

Hi Andres, Ok -- I've added some API for this in 438db0719681: You can get the string pool from the execution session with LLVMOrcExecutionSessionGetSymbolStringPool, then clear that with LLVMOrcSymbolStringPoolClearDeadEntries. -- Lang. On Thu, Oct 1, 2020 at 5:34 PM Lang Hames <lhames at gmail.com> wrote: > Hi Andres, > > Oooh. I think I see. For various reasons the symbol

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

...; > Please let me know, if you ran any more problems with ORCV2. > > Cheers! > > > On Thu, 8 Aug 2019 at 05:12, Zeke Medley via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi folks, >> >> I'm working on migrating a JIT compiler from the old ORCv1 JIT APIs to >> the newer ORCv2 ones and am having some trouble getting the code from >> chapter 1 of the "Building a JIT" [1] tutorial working properly. I >> have previously walked through the "My First Langauge" [2] tutorial >> and that went smoothly usi...

Hi Lang, On Tue, 13 Aug 2019 at 22:15, Lang Hames <lhames at gmail.com> wrote: > >> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an invalid VModuleKey? > > > I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the the VModuleKey is present in the LogicalDylibs map. That means that you have to have used that key in an addModule call, e.g.: > > CODLayer.addModule(K, std::move(M)); > > and not subsequently removed the key with a call to removeModule. Yes indeed that i...

...>> > Cheers! >> > >> > >> > On Thu, 8 Aug 2019 at 05:12, Zeke Medley via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> Hi folks, >> >> >> >> I'm working on migrating a JIT compiler from the old ORCv1 JIT APIs to >> >> the newer ORCv2 ones and am having some trouble getting the code from >> >> chapter 1 of the "Building a JIT" [1] tutorial working properly. I >> >> have previously walked through the "My First Langauge" [2] tutorial >>...