search for: orcmcjitreplacement

Many thanks for the sample code, Alex. In the end I did it the same way OrcMCJITReplacement does it. Constructors and destructors are called and, thanks to LocalCXXRuntimeOverrides, the program does not crash on exit! But it does seem like there should be a simpler way; the learning curve is steep... Geoff On Thu, 21 Jun 2018 at 12:28, Alex Denisov <1101.debian at gmail.com> wrote...

Hello, After commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f we have new warning but only if compiled with GCC: In file included from /path/to/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h:19:0, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9: /path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: 'llvm::orc::JITDylib::SymbolTableEntry::State' is too small to hold all values of 'enum class llvm::orc::JITDylib::SymbolSt...

When OrcMCJITReplacement is given a new module, it asks for the module's constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., and saves the mangled names in a map. Later, to execute them, it uses runViaLayer(), which looks for those symbol names in the given JIT layer. Could one not simply execute...

We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were hoping to create a new ThreadSafeModule, add a GlobalVariable...

...03e05d2f85b5a7e20ec3a3a543584d84f we have new warning >> but only if compiled with GCC: >> >> In file included from >> /path/to/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h:19:0, >> >> from >> /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23, >> >> from >> /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9: >> >> /path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: >> ‘llvm::orc::JITDylib::SymbolTableEntry::State’ is too small to hold all >>...

...h I am using is to add a function to TargetMachine called runFunctionNatively: virtual GenericValue runFunctionNatively(Function *F, void *FPtr, ArrayRef<GenericValue> ArgValues); This houses most of the duplicated code currently in runFunction, and can then be called from either MCJIT or OrcMCJITReplacement. I then have an override for X86TargetMachine that uses the register trick. I'd like to see a generic implementation that can handle all architectures > first, maybe with an specialized version for specific ABIs as an > optimization. > I agree a generic implementation would be ideal,...

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

...what listeners expect: $ grep -h -r -A 1 "NotifyObjectEmitted(" ./include/llvm/ExecutionEngine/JITEventListener.h   virtual void NotifyObjectEmitted(const object::ObjectFile &Obj,                                    const RuntimeDyld::LoadedObjectInfo &L) {} It doesn't break OrcMCJITReplacement as it duplicates the issue and the Info parameter remains unused: $ grep -h -r -A 4 -B 2 "const LoadedObjectInfo &Info" ./lib/ExecutionEngine/Orc/OrcMCJITReplacement.h     void operator()(RTDyldObjectLinkingLayerBase::ObjHandleT H,                     const RTDyldObjectLinkingLayer::...

...har const *);` as closely as possible) to the compiled result. The MCJIT class offers the most convenient API for me, but I'm not sure it is intended for public use as it is not in the include path in a LLVM installation, even when built from source (I am building from the git repo); neither is OrcMCJITReplacement. What is the way that you would suggest to use LLVM's JIT capabilities? It would already help a lot if I knew which function/class names to look up. Thank you in advance for your attention, -- Daniel Campos do Nascimento -------------- next part -------------- An HTML attachment was scrubbed...

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

...the new clang-interpreter example in the source code (top of the tree!), I am able to execute my functions all right... as long as there are no constructors and destructors to call. My question: is there a simple way, with the Orc API, to run a module's constructors and destructors? I see how OrcMCJITReplacement does it, calling getConstructors() and getDestructors() when a module is added, and running them later using a layer, but is there maybe a simpler way that I am missing? I would prefer to avoid having to invent secret names for constructors, play with their linkage and visibility, and generally get...

On Tue, Apr 14, 2015 at 7:24 AM, Lang Hames <lhames at gmail.com> wrote: > > > There are two other Orc-based JITs in tree. One is the MCJIT replacement, > which you'll find in lib/ExecutionEngine/Orc/OrcMCJITReplacement.*, and the > other is OrcLazyJIT, which you'll find in tools/lli/OrcLazyJIT.*. The > former is just emulating MCJIT's behaviour, the latter is doing true lazy > compilation of bitcode. Both are hooked up to lli, and be accessed using > the -jit-kind option. > Any thoughts of...

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is dead/deprecated and projects using it should start > migrating away now? If so, what's the time frame? The short answer is yes: I expect MCJIT to be dep...

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

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I was wondering if there is someone already working on putting the new OrcJIT APIs in the LLVM-C bindings? Also, is there a general consensus to also add C bindings when new major features are added? Hayden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/061f5949/attachment.html>

Heyho, I can only provide you with a screenshot for the first problem I noticed: [https://media.discordapp.net/attachments/534012750045642783/575369402195640321/unknown.png] This code will crash when calling "eeBuilder.create". But I also looked at what happens if I do reuse the llvm::ExecutionEngine. After the call to "finalizeObject" I use "removeModule" for the

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

Hello, I am new to LLVM, and came across a snag when working through tutorials. With the MC JIT execution engine, LLVMRunFunction only works on "main()"-like functions -- other functions fail with the message "Full-featured argument passing not supported yet!". The workaround recommended by the tutorials is to create a main()-compatible wrapper function and to send in

I'm on llvm 3.8.1 and was wondering if there's a memory leak in the removeModule impl of mcjit. In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html a module is removed from the Jit by invoking removeModule. According to the tutorial: "Its API is very simple:: addModule adds an LLVM IR module to the JIT, making its functions available for execution;