similar to: [LLVMdev] Using LLVM to serialize object state -- and performance

I'm not sure I have a clear picture of what you're JIT'ing. If any of the JIT'ed functions call other JIT'ed functions, it may be difficult to find all the dependencies of a functions and recreate them correctly on a subsequent load. Even if the JIT'ed functions only call non-JIT'ed functions, I think you'd need some confidence that the address of the called

Thanks for responding. Sorry for the delay in my reply, but I was dealing with hurricane Sandy. Anyway.... My software build produces libmylib.so. The JIT'd function only calls external C functions in libmylib.so and not other JIT'd functions. The C functions are simple thunks to call constructors. For example, given: class BinaryNode : public Node { public: BinaryNode( Node

Hi Paul, I think you may have gone beyond what I understand in how the legacy JIT code works. It looks like the call to addGlobalMapping should short-circuit the named function look up that I described, but I can't account for why it behaves differently on Mac vs. Linux. I still don't understand how the external pointers persist between writing and reading, but it sounds like you have

Hi I’ve previously used the ExecutionEngine::addGlobalMapping to make existing functions available to my JITed code. I’m currently using ORC, as MCJIT does not appear to be maintained any longer (the kaleidoscope examples have not worked for some time with MCJIT). I’m using just the basic ORC CompileLayer directly. So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.

Hi Andy, I haven't tested this on Linux, but on MacOS the RuntimeDyldMemorManager::getSymbolAddressInProcess method should find symbol addresses in the host program, including symbols from static archives linked into the program. However, one gotcha is that the symbol has to be reachable from main, otherwise the linker may strip it from the final executable. Do you have a test-case that I

Hi Andy, I think that makes sense. I'm currently rewriting the core Kaleidoscope tutorials - I'll look at adding support for this. - Lang. On Fri, Aug 14, 2015 at 7:38 AM, Andy Somogyi <andy.somogyi at gmail.com> wrote: > After some fiddling with it, it does in fact look like it works as you > describe Lang. > > The trick was you had to call > >

Lang, I added the add/get global mapping to my kaleidoscope JIT, but I think perhaps these would make more sense if they were added to the object linking layer as they would be generally usable there. On Aug 19, 2015, at 11:19 PM, Andy Somogyi wrote: > Hey Lang, > > I've added this to my Kaleidoscope JIT, and it seems to work just fine, basically I copied the global mapping

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

Hi, I’m wondering if it’s possible to debug code JIT’ed with the newer ORC JIT. The LLVM documentation has a page at llvm.org/docs/DebuggingJITedCode.html <http://llvm.org/docs/DebuggingJITedCode.html> showing an example of using gdb to debug MCJIT’ed code, but has no mention of ORC JIT. From searching around online I’ve gotten the impression that ORC JIT does *not* support providing

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

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, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via

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

Following up and expanding on an earlier conversation, I'd like to discuss making several non-trivial changes to the MCJIT engine and related objects. There may be some interdependencies between these changes, but I think that they can be logically grouped as follows: * Lazy module compilation * Enhance the JIT memory manager interface to enable section-based memory protection * Clean up

Hi List, I'm trying to upgrade our llvm-c based compiler from JIT to MCJIT. While trying to do so I encountered several problems. Looks like C API does not have proper functions to intialize LLVM with MCJIT. I ended up wrapping the following functions in my own init routine. LLVMInitializeX86TargetInfo(); LLVMInitializeX86Target(); LLVMInitializeX86TargetMC(); LLVMInitializeX86AsmPrinter();

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile

I've been profiling more; see <https://dl.dropbox.com/u/46791180/perf.png>. One thing I'm a bit confused about is why I see a FunctionPassManager there. I use a FunctionPassManager at the end of LLVM IR code generation, write the IR to disk, then read it back later. Why is apparently another FunctionPassManager being used during the JIT'ing of the IR code? And how do I