search for: jiting

Hi, Has anyone had any success with running different PassManagers on llvm::Modules they've already JITed and are executing? In detail: 1) getting the IR, in form of an llvm::Module 2) calling PassManager->run() on the module 3) calling getFunction() and getPointerToFunction() to JIT the module 4) executing the JITed code using the function pointer received in step 3 and then what I

Hi, I found the following wiki page in the Unladen Swallow project: http://code.google.com/p/unladen-swallow/wiki/CodeLifecycle This would appear to answer my question. Could someone confirm for me if it's definitely unsafe to attempt to optimise/JIT any Modules while a different thread is currently executing a JITed function which has been generated from them? Or am I just missing

I have an app that's dynamically generating and JITing code, and will have many such cases in the course of its run. They need to be JITed separately, because I need to execute the first batch before I know what the second one will be. Of course, I *still* need to execute the first after the need for the second arises, so I need to retain the JITed m...

Hi Stephen, I confirm your observation. AFAIK the current JIT keeps informations from the module, for example AssertingHandle on Values. It's part of my plan to make the MCJIT independent from Module stuff to allow reoptimizations, or to have multiple copies of JITed functions for one function in the module, but there is a long road to go. Olivier. On Tue, Nov 9, 2010 at 6:57 PM, Stephen

I am using LLVM to compile script code and then executing using the JIT compiler via the runFunction() method. The script code is contained with a C++ program compiled with G++. I am having a problem when an intrinsic function (i.e. a function implemented in C++ which is called from the LLVM compiled script) throws a C++ exception. I want the exception to be caught by the C++ code that invoked the

I am trying to JIT some code containing an indirect branch (and the corresponding store i8* blockaddress(@label)). I am using LLVM 2.7 code base. I build the ExecutionEngine using EngineBuilder, and call engine->getPointerToFunction(func). When I use setOptLevel(llvm::CodeGenOpt::None), the JITing fails with the following message : JIT.h:131: virtual void* llvm::JIT::getPointerToBasicBlock(llvm::BasicBlock*): Assertion `0 && "JIT does not support address-of-label yet!"' failed. However, when I use setOptLevel(llvm::CodeGenOpt::Less) or higher (Default, Aggressive), th...

...function from the memory manager's getPointerToNamed function, the address you return is going to be written into the JITed code as part of the linking process, so you need a central location to maintain updates to that address. Your approach of linking with a cloned copy of the module (before JITing?) would work too. The main downside I see to that is you may end up JITing multiple copies of functions in the cloned module. That may be OK. Something very similar was done in a project I worked on here at Intel and the results were good. Obviously it's your call as far as weighing the ove...

2012/11/21 Kaylor, Andrew <andrew.kaylor at intel.com>: > If you re-JIT a module that you have previously linked to that will obviously cause some problems, but you can probably work around that with a stub function. could you elaborate a little bit on that ? i was thinking in something different; linking a cloned copy of the module rather than the module directly. Would that work

Hi, I'm trying to work out the correct way of JITing multiple modules. My original approach was to create a new ExecutionEngine for each Module, however this generates an assert failure. If I create a new ModuleProvider for each new Module and then add this to a single ExecutionEngine then I have a problem with static constructors not bei...

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

On Aug 16, 2010, at 3:47 PM, Larry Gritz wrote: > I have an app that's dynamically generating and JITing code, and will have many such cases in the course of its run. They need to be JITed separately, because I need to execute the first batch before I know what the second one will be. Of course, I *still* need to execute the first after the need for the second arises, so I need to retain the JITed m...

Hi all, (thanks to Reid, who gave nice advice) the fibonacci function code works now. Please find attached file. but... the performance is adequate, say, for byte-code interpretation mode and not for optimized JITing. fibonacci function of 35 from attached file is more then 100 times slower then the following code compiled with "gcc -O2" : ----------- #include <iostream> int fib(int x) { if(x<=2) return 1; return fib(x-1)+fib(x-2); } int main(int argc, char**argv) { int n = argc > 1 ?...

On Sat, 14 Aug 2004, Valery A.Khamenya wrote: > (thanks to Reid, who gave nice advice) the fibonacci function code > works now. Please find attached file. > > but... the performance is adequate, say, for byte-code > interpretation mode and not for optimized JITing. > fibonacci function of 35 from attached file is more > then 100 times slower then the following code compiled > with "gcc -O2" : > ----------- > #include <iostream> > int fib(int x) { > if(x<=2) return 1; > return fib(x-1)+fib(x-2); > } > > int...

Hi Björn, I'm not sure I understand what you are actually trying to achieve. Do you want to be able to debug from your main code, and step into the JITed code? Do you want to be able to set breakpoints, list callstacks, etc in the JITed code? Do you want to, from a crash, identify where in your JITed code it went wrong? The first two are definitely one or more order(s) of magnitude harder

...n try to narrow it down to a simple example. In the mean time, perhaps somebody can answer these questions for me: who owns the machine code that is returned by ExecutionEngine::getPointerToFunction? Is that "static" once JITed? Owned by the EE? If I delete the Module and/or EE after JITing, can I still call the JITed code? If not, may I suggest as a future feature either the ability for the client app to take complete ownership of the JIT code, or else to ask the Module/EE to release as many resources and memory as possible except the callable JIT code? -- Larry Gritz lg at larrygr...

My app generates LLVM IR on the fly, JITs, and executes. It also has a backtrace printer installed as a signal handler, that prints a human-readable backtrace if the app crashes. Is there a succinct guide to exactly what I need to do to the LLVM IR I generate (or the calls I make to JIT) so that backtrace() and backtrace_symbols() (on Linux or OS X) can correctly print the call stack when a

Hello LLVM-People, I'm still a beginner with the LLVM, but I really like the concept and the possibilities with the JIT. Currently I compile simple functions with clang-cl into bitcode files. After this I use another program to JIT this bitcode files and execute functions of it - like lli. Thanks to a lot of mails and so on, I understood that a bitcode file is in fact still IR-Code, but

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

I just located a concurrency error in my LLVM patch to add locks to the JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp, which clearly is a problem since This particular issue causes an assertion failure on occasion when running a task that spawns threads on a parallel machine. Any recommendations about if I am doing something that seems horribly wrong are welcome. I'll

On Thu, 21 Apr 2005, Evan Jones wrote: > I just located a concurrency error in my LLVM patch to add locks to the > JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp, > which clearly is a problem since This particular issue causes an > assertion failure on occasion when running a task that spawns threads on > a parallel machine. Any recommendations about if I am