similar to: [LLVMdev] two questions about JIT compilation

Hello I have the following scenario, and I am not sure why the performance is so bad (take 30 minutes to complete with very simple generated functions): 1. Create module 2. Do something like EE = EngineBuilder(theModule).setEngineKind(EngineKind::JIT).create(); 3. Create a function in the module: theModule->getOrInsertFunction(..) 4. Execute 1000 times the function using

Hi Gabi, I have no idea why your performances is not as expected with such low level of informations. But, I know that the binary code is cached by the JIT. You can find the code in JIT.cpp to convince yourself : runFunction -> getPointerToFunction ->getPointerToGlobalIfAvailable which returns the native address of the jitted function. You can even try to measure time needed by each

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

Hi Reid, If an argument is a pointer and the function changes the value it pointed to, do you know how to get that updated value after executing the wrapper function? Thanks. Vu On Tue, Jan 11, 2011 at 2:40 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > On Tue, Jan 11, 2011 at 1:41 PM, Vu Le <vmle at ucdavis.edu> wrote: > > Hi, > > I want to implement a tool

On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> wrote: >> >> >> Then we would always have the location of the br B instruction in A, as it is pushed onto the stack or saved in link register when A calls B. >> > > Right, unless you wanted to go with direct calls in the JIT. I don't know that inspecting a running program's stack

Hi, I found myself doing very similar things to what's discussed in http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-July/009836.html. More precisely, I've modified the clang-interpreter example so that I can specify a .cpp source file at runtime which is JIT-compiled and some functions inside it get called by the interpreter executable itself. In this context, "host-application"

On 11/24/2011 05:52 PM, Óscar Fuentes wrote: > Óscar Fuentes<ofv at wanadoo.es> writes: > >>>> If I activate the Inliner pass: >>>> >>>> Builder.Inliner = createFunctionInliningPass(Threshold); >>>> >>>> this is the result: >>>> >>>> LLVM ERROR: Program used external function

Hi Andrew, Andrew Haley wrote: > 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

If you know the prototype of f, you can just use getPointerToFunction and cast the result: // Let F be an llvm::Function* referring to 'f'. void (*f)(int*) = (void (*)(int*))JIT->getPointerToFunction(F); int a; f(&a); // read a I haven't compiled this, it's a guess at the usage from memory. Reid On Fri, Feb 11, 2011 at 12:55 PM, Vu Le <vmle at ucdavis.edu> wrote:

I guess we'll have to add that to the list of things that needs to be done to replace the old JIT. In the projects I've worked on that use MCJIT, we've been using getPointerToFunction and then calling it from outside the MCJIT engine, but I suppose that the generic handling in runFunction would be useful in some cases. -Andy -----Original Message----- From: llvmdev-bounces at

Hello Eli. Eli Friedman <eli.friedman at gmail.com> writes: >> If I activate the Inliner pass: >> >>    Builder.Inliner = createFunctionInliningPass(Threshold); >> >> this is the result: >> >> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >> >> It happens on almost all my test

Hi, I want to implement a tool that probes a function with several input and records all the return output. The function might have more than 1 return value (by reference parameters). Does ExecutionEngine::runFunction() support function call with complex argument type? If not, I guess that I have to create a wrapper function, prepare all the data, and call the original function. Am I on the right

Óscar Fuentes <ofv at wanadoo.es> writes: >>> If I activate the Inliner pass: >>> >>>    Builder.Inliner = createFunctionInliningPass(Threshold); >>> >>> this is the result: >>> >>> LLVM ERROR: Program used external function 'llvm.lifetime.start' which could not be resolved! >>> >>> It happens on almost

Hi Andrea, As I understand it, when the JIT emitter encounters a function call, it attempts to get a pointer to the function from the JIT engine by calling the JIT::getPointerToFunction() method. If the JIT engine isn't able to associate the function with an existing known function and can't JIT it, it will attempt to lookup the function by name. One of the ways it attempts to do so is

I have a function in llvm ir as follows: def [2 x [3 x double]] @fun() { return [ ... ]; // a [2 x [3 x double]] constant } I would like to JIT this function in C. I first get the void pointer using: void *FPtr = TheExecutionEngine->getPointerToFunction( func ); Then I need to conver this void pointer to the corresponding C function pointer type, and then call the function

Thanks Andrew, that makes sense actually. Just one thing, about the last point in my original email: all functions defined in the plugin will instead have to be explicitly declared extern "C" or I have to, somehow, obtain the mangled name (and what's the best/safest way to do that) if I want llvm::Module::getFunction to succeed? Andrea. On Apr 16, 2012, at 7:36 PM, Kaylor, Andrew

On Apr 1, 2011, at 9:38 AM, Reid Kleckner wrote: > On Thu, Mar 31, 2011 at 11:15 PM, Eric Christopher <echristo at apple.com> wrote: >>> >>> >>> Then we would always have the location of the br B instruction in A, as it is pushed onto the stack or saved in link register when A calls B. >>> >> >> Right, unless you wanted to go with

Regarding the nocapture attribute the language ref says: "the callee does not make any copies of the pointer that outlive the callee itself". >From I inferred that it is OK for the callee to make a copy of the pointer that doesn't outlive the call. However if I write some code that does this the optimizers don't do what I'd expect. Consider the following the example:

Óscar Fuentes <ofv at wanadoo.es> writes: > Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As > all "external" functions are provided by the language's FFI mechanism, > it does > > MyExecutionEngine->DisableSymbolSearching(); > MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); > > which works fine

On Thu, Mar 31, 2011 at 11:07 PM, Eric Christopher <echristo at apple.com>wrote: > > > > > > No we will always have control over where the parent calls the functions > that we are recompiling. As explained in the example below > > > > Original Code > > > > Binary for A: Binary for B: > > > > ... ...