similar to: [LLVMdev] GCModuleInfo and MCJIT

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

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

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'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,

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

Thanks, Anton. I always forget about llvm-admin :). I'd say converting all branches would be best, would help track the MCJIT work for example. Gaël, does that sound good to you? You're the one making all the commits these days :). ~Will On Sun, Jan 5, 2014 at 9:03 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > I can create a mirror, this is not

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

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

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

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

Ok, I have exactly the same problem when I compile, I will try to understand where is the problem. Gaël 2013/11/21 Gaël Thomas <gael.thomas00 at gmail.com>: > Arg, you have to use a version strictly before the 7u25 (probably the > 7u21), sorry! > > I hope that it will work, because I also have problem to compile the > trunk version of vmkit (I haven't tested the trunk

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

Is there a particular revision in the repository that I can checkout and work from? Thanks, -- Adam On Thu, Nov 21, 2013 at 3:46 PM, Gaël Thomas <gael.thomas00 at gmail.com> wrote: > Ok, I have exactly the same problem when I compile, I will try to > understand where is the problem. > > Gaël > > 2013/11/21 Gaël Thomas <gael.thomas00 at gmail.com>: >> Arg, you

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

Oups, sorry for the mistake, llcj (not llc:)) is not more maintained! Gaël Le 10 sept. 2014 00:27, "Gaël Thomas" <gael.thomas00 at gmail.com> a écrit : > Hi Brian, > > So, I confirm, llc is not more maintained. And using vmjc is probably > the good starting point to translate Java bytecode into llvm bitcode. > > However, I think that your hack (changing the way