similar to: New ORC v2 LLJIT - global variables

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

Hi, On 2020-10-01 15:29:12 -0700, Lang Hames wrote: > 24bytes / object -- Looks like I managed module ownership correctly but > leaked the ThreadSafeModule container. This should be fixed in 5044196b412f. That helped a bit, but not yet fully. Looks like it might be still reachable memory, so leakcheck isn't that helpful. Oooh. I think I see. For various reasons the symbol names we

Hi, We are using the new LLJIT class in our compiler. We have not been successful using the parallel JIT feature. When we tried it previously on multiple modules, our compile-time increased significantly. I don't know if we are using it incorrectly, or that we miss out on optimizations we get when running on a single merged module, but it hasn't worked for us yet. We are pretty far behind

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: /** *

Hello LLVM developers, I am developing a small project using LLVM. The objective is to provide dynamic loading via JIT compilation of C++ code contained in a (TS) module. For this reason, I would like to return an explicitly raw void pointer (resembling libdl's `void *dlsym(void *, char const *);` as closely as possible) to the compiled result. The MCJIT class offers the most convenient API

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:

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

On 01/14/2015 02:33 PM, David Blaikie wrote: > > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com > <mailto:lhames at gmail.com>> wrote: > > Hi Dave, > > To confirm - I have no plans to remove MCJIT. I don't want > to change any behavior for existing clients. The new stuff > is opt-in. >

Hi Dave, To confirm - I have no plans to remove MCJIT. I don't want to change any >> behavior for existing clients. The new stuff is opt-in. >> > > Why not? We did work to remove the legacy JIT in favor of MCJIT for the > usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to > then go back to maintaining two JITs again. > > You mention

Hi Philip, In terms of the overall idea, I like what your proposing. However, I want > to be very clear: you are not planning on removing any functionality from > the existing (fairly low level) MCJIT interface right? > To confirm - I have no plans to remove MCJIT. I don't want to change any behavior for existing clients. The new stuff is opt-in. > We've built our own

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

Hi, I had similar problems with EH in ELF in RTDyldMemoryManager::registerEHFrames() calling __register_frame(). I'm not sure these problems are related to this problem since your crash happens in RuntimeDyldMachO::registerEHFrames() in its own processFDE (there are two functions named processFDE(), one in RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp) *before*

Hello friendly LLVM-World, because I don't know if I had send my problem to the correct Mailing-List, I will send my problem to this address too. I'm not subscribed to this list, so please add my in CC if you response. Kind regards Björn From: Bjoern Gaier/HE/HORIBA To: Clang Dev <cfe-dev at lists.llvm.org>, "cfe-dev" <cfe-dev-bounces at lists.llvm.org>

Hello Stefan, I'm happy someone replied to my problem! Many thanks! To be honest... I didn't understood much of your mail. I'm a beginner with the JIT - so I will explain what I've done. To manage the memory and resolve symbols, I'm using my own Resolver-Class, which overloads the allocation and the findSymbol functions. I've noticed today, that the

Hi Björn To first answer your questionin the subject: For x86 registerEHFrames() is only a stub. For x86_64 registerEHFrames() is implemented properly in RuntimeDyldCOFFX86_64, calling MemMgr.registerEHFrames() for each EH frame section. It should be called and work out of the box without your involvement, but unfortunately it won't solve your issue. All the essential information is there in

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:

I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function. It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE. The weird part is that the function does not appear to do anything special and I've whittled it down to the minimum size that still causes the crash. If I remove even one

Hi Christian, Thanks for sharing this. Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related. It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of

> I tried loading the "msvcrt.lib" as a archive. That was... a bad idea! > I get a Exception while loading: > Assertion failed: ((int64_t)Result <= INT32_MAX) && "Relocation > overflow", file > \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81 It's a limitation of the COFF/PE format and unrelated to exceptions. This patch

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 the constructors straight away, rather than naming them and looking them up