search for: orcv2

...ls to functions. If I subsequently define another function in the same repl session and call it, it uses the results of the first function call in that repl session: ready> def bar(x) x + 1; ... ready> bar(1); Evaluated to 102334155.000000 I suspect that this has to do with the fact that in ORCv2 we can no longer remove modules meaning that the code in HandleTopLevelExpression can't wrap up by removing the most recent module it added. The tutorial does lookups by creating a function with no arguments names "__anon_expr", calling it, then removing it AFIK and because ORCv2 does...

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

...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 shorten the compilation time? Is it possible to compile this single big IR Module with MCJIT in parallel? Is OrcV2 JIT faster than MCJIT? Can the 'concurrent compilation' feature mentioned in Orcv2 webpage help on this? Thanks in advance for any advice. This is how I organized the optimization pass: LLVMAddBasicAliasAnalysisPass(comp_ctx->pass_mgr); LLVMAddPromoteMemoryToRegisterPass(comp_c...

...ally 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 that ORCv2 doesn't support code removal (yet). To work around that we need to rename the anonymous expression each time (e.g. __anon_expr.1, __anon_expr.2, ...). Sounds like we're not doing that at the moment. I'll try to get it fixed up shortly. > > Cheers, > Lang. > > On Thu, Aug...

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

...> dbgs() << "Before optimization:\n" << *M << "\n"; > for (auto &F : *M) > FPM->run(F); > dbgs() << "Before optimization:\n" << *M << "\n"; > > I expect that output to be the same for both ORC and ORCv2. If not something is going wrong with IR optimization. Well for ORCV2 there is no change before and after. I also get this message: JIT session error: Symbols not found: { raise_error } Yes raise_error and all other extern functions are explicitly added as global symbols. > > CodeGen opti...

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' method. - For an LLJIT instance you can just call the 'addOb...

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 into three pieces: - OrcJIT retains the bulk...

...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 lists (make sure you CC me) or #llvm on discord. There are also some tips available in https://llvm.org/docs/ORCv2.html . (2) LLVM has a new JIT linker, JITLink, which is intended as...

...p 28, 2020 at 10:57 PM Lang Hames <lhames at gmail.com> wrote: > > > > 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' method. &gt...

...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 planning on using ORC to >...

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

Hi All, This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2. Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337): When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to be discarded (rough...

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

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

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

...what a simple LLJIT API should look 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'...

...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 problem. Code is still not getting optimized at all. I don't really know what is going on. Yet the same setup works fine with the Legacy ORC v1 setup. Any help is appreciated. Here are again the links to the...

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

...er 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 machines update at the same time). 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 doesn't yet fully work. Greetings, Andres Freund