similar to: [LLVMdev] LLVM JIT in multi-threaded environments

Since my last question was a bit long, I'll keep this short: What is the "best practice" way to use LLVM JIT in a multithreaded application? I've noticed there can only be one JIT ExecutionEngine present in the application, and putting the engine in a singleton instance doesn't seem to work. Thanks, Eric Yew -------------- next part -------------- An HTML attachment was

Hi, Was this ever resolved? I'm curious, I'm also in a situation where there may be many (very many) JITted functions over the history of an application (which may be running for many days) Thanks On Mar 20, 2009, at 7:34 AM, George Giorgidze wrote: > Hi, > > In my application I am JITing thousands of functions, though I am > doing it sequantially and running only

Hi, In my application I am JITing thousands of functions, though I am doing it sequantially and running only one at a time. So it is crucial to be able to properly clean up the memory from an old JITed function when JITing and running the new one. I am using Haskell binding of LLVM and my application works OK. However, memory usage increases and never decreases during the run time of my

Hi, all I can not figure this out, please have a look and help me out. thank you! Note: this is in SPLUS, not R. I have following code *********************************** modfit<-function(yir,yew, ft) { n<-length(yew) yew<-yew[1:(n-1)] yy<-yir-ft xx<-yew-ft n<-length(xx) xx0<-xx[2:n] yy0 <-yy [2:n] xx1<-xx[1:(n-1)] fit <- garch(yy0~xx0 + xx1+var.in.mean,

Hello Everyone, Does void JIT::freeMachineCodeForFunction(Function *F) work on arm? I get a crash when I call it on arm.I don't have access to gdb on the simulator I am using , so can't say for sure if it works. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello Everyone, Does void JIT::freeMachineCodeForFunction(Function *F) work on arm? I get a crash when I call it on arm.I don't have access to gdb on the simulator I am using , so can't say for sure if it works. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > >> So I (think I) found a bug in the JIT: >> http://llvm.org/bugs/show_bug.cgi?id=4483 >> >> Basically, globals used by a function are allocated in the same buffer >> as the first code that uses it.  However, when you

On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote: > On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> > wrote: >> >> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: >> >>> So I (think I) found a bug in the JIT: >>> http://llvm.org/bugs/show_bug.cgi?id=4483 >>> >>> Basically, globals used by a

Hello, The problem I'm having is that I modify a function body by using 'Value::replaceAllUsesWith' and then execute it with the JIT engine several times but I always get the output from the first iteration for all the iterations. This is what I do: I generate the following 2 functions on the fly based on the FunctionType of the declaration below in C code. define i32

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 turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static

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 Chris, Thanks for pointing me to that presentation! It helped me come up with a strategy that I believe might work: 1) Use CloneFunction() to make a copy of the original unspecialized (but optimized) function. 2) Specialize it using a custom function pass which identifies the specialization parameters and substitutes them with given run-time constants. 3) Run the function through a

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

Hi All, I just implemented an often-requested feature: the ability to delete machine code out of the JIT's code buffer (the ExecutionEngine::freeMachineCodeForFunction(F) method). The implementation uses a very general free-list mechanism for tracking free ranges in the buffer, and it works perfectly in my simple test cases designed to cover all of the code paths. However, I don't

Hi all, I'm playing with the JIT trying to find out the best way to handle a genetic algorithm that we are developing: I need to: 1) generate about 50.000 functions a time 2) JIT them and execute them over a large dataset 3) Discard everything 4) ... stuff... 5) Loop to 1 again and again and again... I've the code running, under LLVM 2.0 on OS X 10.4.10 but it leaks, so I started to

+llvmdev 2009/7/3 Merkulov Aleksey <steel1.0 at mail.ru>: >> > Hello!  Working with LLVM JIT-compiler I found a small bug and I'd like to correct it.  Namely, on some tests LLVM fails with message "JIT: Ran out of space for generated machine code!" >> >> I'm working on a patch to fix this, although I've heard DOE may change >> the

> > > My bet is that your code is writing through a stray pointer. By > > > removing the call to InitializeNativeTarget you are simply hiding > > > your bug by running the code within a context that turns its effects > harmless. > > > > > > OTOH, LLVM 2.9 may be the culprit. In any case, it is time for a > > > assembler- level debug session

Thanks for the patch! I'll clean this up, convert your sample to a unit test, and commit it for 2.7. On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > Hi Jeffrey, > > Thanks for pointing me in the right direction ! > I'm not using the JIT in lazy mode, but it was fun to understand the > lazy-stub code. > > Attached you will

getFunction() -> getPointerToFunction() 2014-06-29 6:40 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Hi Adrian, > > freeMachineCodeForFunction is required but recompileAndLinkFunction is > not, > you can use getFunction() always. > > Try to M->dump() calling M->getFunction() where M is the Module *. > See if how the changes appear in the module