similar to: [LLVMdev] Eager JIT

Sure, you can turn off lazy compilation. Take a look at NoLazyCompilation in lli.cpp. Evan On Jul 7, 2008, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > Is there any way to generate the binary code for a whole module at > once? Currently I always get lazy compilation one function at a time. > > The reason I would like to generate the whole module at once is >

Hi Olivier, On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > Hi Garrison, > > I finally come back from holidays and take time to watch your patch. > > I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? JIT::forceEmitFunctionStub(...) was created to

Hi Evan, Thanks a lot for the information! It's a viable solution to write my own JITMemoryManager, however I noticed that the JIT doesn't know the length of the binary function before it is actually emitted. This is a bit inconvenient especially since I have to generate new functions at irregular times. I'm not too keen on using the non-standard _expand function to resize

Hi all, I'm using LLVM to generate a fairly large number of separate functions at run-time. To minimize the memory overhead, I'd like to delete the IR and everything else that is no longer needed after a function has been generated (I don't use lazy compilation or anything like that). I noticed that deleting the ExecutionEngine deletes everything (Module, Function(s),

When JITEmitter is teared down, it also deletes the JITMemoryManager instance. That in turns release the memory of the generated functions. Is this what you are referring to? The DefaultJITMemoryManager is pretty simple. You can obviously write your own memory manager class that maps the memory in a way that's persistent. Then all you have to do is to pass a handle of it to

On Fri, Aug 20, 2010 at 12:39 PM, Larry Gritz <lg at larrygritz.com> wrote: > On Aug 18, 2010, at 10:24 AM, Reid Kleckner wrote: > >> You can free the machine code yourself by saying >> EE->freeMachineCodeForFunction(F) .  If you destroy the EE, it will >> also free the machine code. > > Thanks, but unfortunately, this is exactly the opposite of what I want

On Aug 18, 2010, at 10:24 AM, Reid Kleckner wrote: > You can free the machine code yourself by saying > EE->freeMachineCodeForFunction(F) . If you destroy the EE, it will > also free the machine code. Thanks, but unfortunately, this is exactly the opposite of what I want to do. I need to retain the machine code indefinitely, but I want to free all possible other resources that are

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

On 2008-04-02, at 05:55, Gary Benson wrote: > I've been working on making a non-architecture specific port of > OpenJDK these past few months. It's interpreter-only at present, > and very slow, and I'd like to use LLVM to add some kind of JIT to it. > > So far I'm just trying to figure out how it would all slot in. The > existing code in OpenJDK is written

Hi all, I am new to LLVM so I apologize if my question seem lame to you. I was trying to understand the way in which MCJIT generates the stub functions when it encounters any functions which are not compiled yet. As far as I have looked into the code, the probable code which can do this is void *JIT::getPointerToFunctionOrStub and this is in JITEmitter under JIT. I may be wrong here though.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been reading the headers and http://llvm.org/releases/2.1/docs/ProgrammersManual.html and I'm still confused about a pretty fundamental point... who is expected to clean up various objects when we're finished with them, and when? Let's say I've created a module, retrieved a bunch of types, created a function, a basic block,

Hi, > Is it possible to keep adding bitcode incrementally to the > system, and JIT'ing it, and have the set of functions > defined in the system keep growing, so that the next hunk > of bitcode added can have access to all the functions > defined so far? Yes. The JIT supports lazy compilation mode where it will generate thunks that only get compiled/linked when called - see

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > Yes, you should be able to inherit from

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

On Mon, Jan 14, 2013 at 4:56 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote: > Hello all, > > I've already bothered people on IRC with this question and it was > recommended to ask it here. > > First of all, some context. In Rubinius (http://rubini.us/, > http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create > LLVM IR using the C++ API and

Hi Garrison, I finally come back from holidays and take time to watch your patch. I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ? I thought about JIT and modules, and I wonder if we don't need to take it another way. Now we can create multiples JIT. What if we

This is the second version of a patch, which I recently attached to bug 2606, whose original version was modified to reflect the lists comments. Also please note the comment at the end of this email, which basically questions whether this bug is really a bug. 1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > > > Yes, you should be

Hi! It appeared to me that runFunction in JIT.cpp is slow for repeatedly executing the same function with nontrivial arguments since the "Stub" function in JiT.cpp:183 (LLVM 1.9) is compiled again and again. Is there something I can do to accelerate this? g