similar to: [LLVMdev] LLVM JIT Questions

Hi Dmitri, Regarding your first question, if you can use the MCJIT engine a caching mechanism will be available very soon. I'm preparing to commit a patch today to add this capability. I'm not sure what it would take to get something similar working with the older JIT engine. I expect it would take a fair amount of work because the older JIT engine isn't designed around object

On Tue, Apr 23, 2013 at 10:39 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi Dmitri, > > Regarding your first question, if you can use the MCJIT engine a caching > mechanism will be available very soon. I'm preparing to commit a patch > today to add this capability. I'm not sure what it would take to get > something similar working with the older JIT

This sounds great, but will it work on Windows as well ? I considered MCJIT for my work, but was not sure if there are any features supported by old JIT but missing in MCJIT. Thanks, Dmitri Am 23.04.2013 20:26 schrieb "Kaylor, Andrew" <andrew.kaylor at intel.com>: > Yes, exactly. My patch adds a new ObjectCache class which can be > registered with MCJIT. MCJIT will

Yes, exactly. My patch adds a new ObjectCache class which can be registered with MCJIT. MCJIT will then call this component before attempting to generate code to see if it has a cached object image for a given module. If the ObjectCache has a cached object, MCJIT will skip the code generation step and just perform linking and loading. If the ObjectCache does not have a cached version MCJIT

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

Hi Dmitri, You're right. The lli code should be cleaned up. As David said, there was a time when the call to invalidate the instruction cache was necessary. It isn't necessary anymore. -Andy -----Original Message----- From: Dmitri Rubinstein [mailto:dmitri.rubinstein at googlemail.com] Sent: Tuesday, June 04, 2013 7:20 AM To: David Tweed Cc: Kaylor, Andrew; LLVM Dev Subject: Re:

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

Am 04.06.2013 16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call

Thanks Andrew for the update. Does it support NotifyFunctionEmitted? Cheers. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:06 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC The current 3.2 code branch has events being broadcast from the MCJIT engine

I see. If I am writing my own listener can I still get back the (llvm::Function, void* Code, size_t Size)? Ciao. -----Original Message----- From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Monday, November 26, 2012 1:24 PM To: Manny Ko Cc: LLVM Developers Mailing List Subject: RE: [LLVMdev] Removing old JIT CodeEmitters for ARM and PPC No. It adds a new event,

Hi Yaron, I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it's probably best for your code to manager the function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it's my understanding that the Julia runtime handles function stubs

No. It adds a new event, 'NotifyObjectEmitted'. The Intel JIT listener that I mentioned then uses the emitted object to find the functions (which are all emitted together). Because of the way that MCJIT is implemented, it isn't really feasible to reconstruct things like the EmittedFunctionDetails in the NotifyFunctionEmitted event. -Andy -----Original Message----- From: Manny Ko

It seems wrong to delegate a dozen or more methods when I only want to change the behavior in a couple small ways. It would have been easier to derive a class, but the base class is inaccessible (in an anonymous namespace). And I was afraid to roll my own memory manager because I didn't understand what all those methods do. So MCJIT is future - will JITMemoryManager remain relevant? If so I

Hi Andrew, hi all, I already saw that the old jit was (almost) deprecated. So, I'm currently playing with the new jit and it's look very interesting. (I'm working locally and I haven't pushed anything new on VMKit because I'm also changing a little the design vmkit). For the moment, MCJIT does not work with VMKit (but I haven't yet tested the safepoint/stackmap patch), I

The functionality of MCJIT vs JIT had diverged. Not only they have different operating models (lazy function vs. multi-module), the API is almost completely different. There is a set of functions just for JIT, another set of functions just for MCJIT, with comments saying which ones work for JIT and which ones work for MCJIT. It would make sense for the EE to have only the shared functionality

Hi Andy, I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates

Hi Andy, Thanks for the answer. I'm currently reading the internal code of MCJIT and it's really a great work (I was only using the ExecutionEngine interface for the moment). So, I agree, all what I need is already in the code (see below) :) 2013/11/14 Kaylor, Andrew <andrew.kaylor at intel.com>: > Hi Gaël, > > Thank you for the detailed explanation. It's very

Hi Gaël, I would guess that MCJIT is probably attempting to load and link the shared library you return from the ObjectCache in the way it would load and link generated code, which would be wrong for a shared library. I know it seems like it should be easier to handle a shared library than a raw relocatable object (and it probably is) but MCJIT doesn't handle that case at the moment. The

Hi Andrew (hi all:)), I perfectly understand the problem of relocation and it's really not a problem in my case. I'm still trying to make MCJIT runs but I face a small problem. I have to insert callback to the runtime for functions provided by vmkit (for example, a gcmalloc function to allocate memory from the heap). With the old JIT, VMKit simply loads a large bc file that contains all

Hi Gaël, I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it. However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but