similar to: [LLVMdev] (Very) small patch for the jit event listener

Hi Andy, We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides great

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

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

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, Thank you for the detailed explanation. It's very helpful. All of the things you describe could be done within MCJIT, but I'm not sure that's where they belong. We had a discussion about lazy function compilation at the LLVM Developers Meeting last week and the consensus among those present was that it would be better to leave this sort of lazy compilation to the MCJIT

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 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 Gaël, I'm glad to hear that MCJIT looks promising to you. > I understand the point. Probably that providing a small example that describes how using > advanced features of MCJIT could help. If I can manage to make MCJIT works with VMKit, > I'll be happy to send you an example of lazy compilation that highlight some of the features > of MCJIT. I'd love to have a

Hump, I think that I have to solution, but I have a new problem (more serious). For the solution, it's stupid, I have simply loaded the shared library in ObjectCache::getObject directly in a MemoryBuffer :) As the linker understand a .o, it understands a .so. Now, I'm able to compile a module (I call finalizeObject()), I'm able to find my first generated function pointer, but I'm

Hi Andrew, Thank you very much for all your help! So, I have tested without my shared library (with a relocatable object and without) and still, my code is not executable. I was testing my code with multiple modules and I don't now if using multiple modules is fully functional? Anyway, I'm now allocating a mcjit for each function to be sure. But now, I have a new problem that comes

Hi Gaël, Multiple module support should be fully functional. However, there are some oddities in how MCJIT gets memory ready to execute, particularly if you are using the deprecated getPointerToFunction or runFunction methods. If you use these methods you'll need to call finalizeObject before you execute the code. I've heard reports that there's a bug doing that after adding

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that

Hi, I have the solution to my problem :). And the llvm gc infrastructure can work with the current MCJIT without any change (good news). I will explain what I have done to find the garbage collector metadata generated by llvm with MCJIT, I'm pretty sure that it could help someone. And it's very easy. You just have to activate a static gcprinter for the assembly. A very good example is

Ok I see. Of course, at runtime, it's enough for dynamic linking or for deoptimization. However, wmkit acts both as a jit and as an aot. For the aot, it means that I can not use patchpoint and that I should have two different compilation strategy. It's not so difficult, but in this case, I can not use patchpoints to generate gc's stackmap for the aot (basically, I think that I could

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily

Hi Gael, I tried converting to your approach but I had some issues making sure that all symbols accessed by the jit modules have entries in the dynamic symbol table. To be specific, my current approach is to use MCJIT (using an objectcache) to JIT the runtime module and then let MCJIT handle linking any references from the jit'd modules; I just experimented with what I think you're doing,

Hi all, I'm trying to play with patchoint (with MCJIT and VMKit) and I don't understand something. I generate this call for my first patch point. Basically, I want to call f(0). %5 = call i64 (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.i64( i64 42, ;; patch point id is 42 i32 0, ;; 0 bytes for the padding i8* bitcast (i32 (i32)* @f to i8*), ;; my function f i32 1,

patchpoint is intended to be used in VMs that do their own linking, and so you wouldn't expect the function parameter to be resolved by LLVM. Presumably, in VMKit, you could just plant a pointer constant to the function you wish to call initially? -Filip On Dec 17, 2013, at 2:42 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Hi all, > > I'm trying to play with