Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] (Very) small patch for the jit event listener"
2013 Nov 13
0
[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
2013 Nov 14
2
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 13
3
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 15
0
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 14
2
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 14
0
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 16
2
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 18
2
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 14
0
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 16
0
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 19
0
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Nov 19
1
[LLVMdev] (Very) small patch for the jit event listener
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
2013 Dec 15
2
[LLVMdev] GCModuleInfo and MCJIT
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
2013 Dec 18
0
[LLVMdev] GCModuleInfo and MCJIT
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
2013 Dec 18
1
[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
2013 Dec 18
2
[LLVMdev] Trying to use patchpoint in MCJIT
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
2013 Oct 23
2
[LLVMdev] GC StackMaps (was Stackmap and Patchpoint Intrinsic Proposal)
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
2014 Jan 26
2
[LLVMdev] MCJIT versus getLazyBitcodeModule?
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,
2013 Dec 17
3
[LLVMdev] Trying to use patchpoint in MCJIT
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,
2013 Dec 18
0
[LLVMdev] Trying to use patchpoint in MCJIT
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