similar to: ORC JIT Weekly #2 -- COFF COMDAT Constants and Emulated TLS

Hi All, In the interests of improving visibility into ORC JIT development I'm going to try writing weekly status updates for the community. I hope they will provide insight into the design and state of development of LLVM's JIT APIs, as well as serving as a convenient space for discussions among LLVM's large and growing community of JIT API users. The length and detail will vary

Hi Andres, I also want to highlight the necessity of some form of C API, that others > already have. > <snip> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the > possible features, though. Ok. This got me thinking about what a simple LLJIT API should look like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'

Hi Geoff, We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work > for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at

Hi Andres, A topic that I'd find interesting is what it'd take to make it easier to > use profile guided optimization in the context of JIT. A few years back > I crudely hacked this together, but it was fairly ugly. It'd be nice to > make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and

Dear Geoff, As for as ORCv2 is concerned, there is no event listener facility available as of now. Thanks On Fri, 20 Dec 2019 at 01:21, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang Hames <lhames at gmail.com> the author/owner of the ORC JIT - though > he's out of teh office at the moment I think, so might not get a reply > until the new year

Hi, On 2020-09-30 17:52:46 -0700, Lang Hames wrote: > I've just realised that we're going to need a change to the definition > generator API in the long term: Right now it is called under the session > lock, but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time

hello folks, I'm working to add runtime updating of code to the OCaml compiler which in its bytecode guise presents no barrier because there is only one linker and it is written in that language and full control is available. With native code on the other hand, there is reliance on the system linker and I got completely lost examining the GNU ld/dl library source code. The prospect of

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

Hi there, I am trying to JIT a rather big wasm bytecode program to x86 native code and running into this JIT compilation time issue. In the first stage, I use MCJIT to translate wasm bytecode to a single LLVM IR Module which ends up with 927 functions. Then it took a pretty long time to apply several optimization passes to this big IR module and finally generate x86 code. What should I do to

Hi Praveen, Thanks for pointing that out :) That's my mistake. I might have been misidentifying the issue with the assert statement. With those fixes made function calls seem to all call the first function called in the REPL. For example: ready> def fib(n) if (n < 2) then n else fib(n - 1) + fib(n - 2); ... ready> fib(40); Evaluated to 102334155.000000 ready> fib(10); # This

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 the one from the JIT

Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before

HI Lang, Thanks a bunch for the reply. That worked great for on my end and is a pretty tiny change. Really appreciate all the work you've done on this new JIT stuff and putting together those great tutorials. Zeke On Thu, Aug 8, 2019 at 3:07 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Zeke, > > Thanks for pointing this out. > > You're right: the issue is

Hi All, I've added a very basic set of C bindings for OrcV2 in 633ea07200e, with an example in llvm/example/OrcV2Examples/BasicOrcV2CBindings. Development of the C APIs is being tracked by http://llvm.org/PR31103 -- if you're interested in C APIs for OrcV2 please get involved. I would especially appreciate feedback and patches from C API users: I don't have a use case for the C APIs

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library

Hi, I am still on LLVM v6 as v7 ORC api changes were not backward compatible. Has the ORC api stabilized now with v8, or is it still under flux? Thanks and Regards Dibyendu

Hi Lang, On Tue, 13 Aug 2019 at 20:47, Lang Hames <lhames at gmail.com> wrote: > > Sorry for the delayed reply. Looks like you have figured out how to solve your issue already. Out of interest, what did you need to do? Do you have anything that you would like to see added to http://llvm.org/docs/ORCv2.html ? > Sorry my post was misleading. I figured out below which was part of the

Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more

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