similar to: ORC JIT Weekly #8: Basic OrcV2 C Bindings, MachO and COFF improvements.

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, I updated my project to LLVM 10.0 today and I am getting JIT symbol resolution errors. I could not find any example or updated tutorial or documentation that describes the new api - as all documentation seems out of date. I paste below some code snippets that show what I am doing: /* global syms is a array mapping names to function addresses */

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 All, Just a couple of updates this week: First: there is a preview patch up at https://reviews.llvm.org/D75838 to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've only done very preliminary testing on it, but was able to debug simple JIT'd programs on Linux using the GDB registration listener. If you've been wanting to move to ORC but held up by lack of debugger /

Hi All, There was only one interesting ORC-specific commit this week: A new example showing how to initialize and de-initialize JITDylibs has been added in llvm/examples/OrcV2Examples/LLJITWithInitializers. The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC

Committed to 11.x as b6efbd6b5f22d0a251d2fba9a5d24ac21760b1cc. Thanks! On Thu, Oct 1, 2020 at 3:29 AM Lang Hames <lhames at gmail.com> wrote: > > Hi Hans, > > Apologies if I got here too late, but just in case I didn't here are some JIT release notes for 11.0.0: > > - LLJIT now supports execution of static inits / deinits via the LLJIT::initialize and

Thanks! Committed in 158581772fc8f3d6c601ceba14a08285e46cb7e9 On Tue, Sep 15, 2020 at 4:23 PM Ahsan Saghir <saghir.ibm at gmail.com> wrote: > > Hi Hans, > Here are the PowerPC release notes for 11.0.0: > > Optimization: > > Improved Loop Unroll-and-Jam legality checks, allowing it to handle more than two level loop nests > Improved Loop Unroll to be able

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

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

Heyho, Recently I tried out the ORCv2 JIT, especially the LLJIT. I gotta say, that I really like the new interface and the way you use it! However there is one thing I'm missing. I wrote a small bit code file, which should force having a global constructor. int wuff(); __declspec(noinline) int miau() { printf("Huhuhu"); return wuff(); } const int x = miau(); When I

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

I too am in the process of porting our ORC code to ORC v2 and LLJIT. The new API allows me to remove much of our own code, which can only be a good thing. I sometimes get crashes, however, when executing my JIT compiled function, so I thought I would use gdb to try to figure out what is going wrong. And I am dismayed to see that there seems to be no way to provide an event listener to register

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