similar to: [LLVMdev] JIT slow

Hi, > Okay. If the function exists in your application's address space > already, > just name the LLVM function the same name as the native function > and the > JIT should find it an do the right thing. This is how it finds > printf and > a variety of other things. You don't need to call addGlobalMapping at > all. Looking at the output of "nm

Hello, I'm new to LLVM and I had a question about it: when we call the JIT::runFunction, since llvm doesn't has a full FFI, there are some cases in which the JIT needs to codegen a stub function to call the function we are interested, my question is: this stub function will remains in the module until when ? What are the most efficient way to remove it from the module and memory ? For a

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

Hi, I was able to try this on linux again. Unfortunately it doesn't work at all (neither using runFunction nor a CallInst). It simply says function called get5 not known. Calling printf the same way works, though. On linux the function is exported as "get5" from the executable while it is called "_get5" on OS X. I could not spot any other differences.. any

On Tue, Jan 11, 2011 at 1:41 PM, Vu Le <vmle at ucdavis.edu> wrote: > 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

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

Reid Spencer, thank you for your quick responce, finally i got to my PC at home. You wrote: > Attached are three files: "valery.cpp" which contains your original, > "reid.cpp" which contains corrections to most of the FIXME items and > "diffs" which shows the differences between them. The differences > should be instructive on what to do. You were

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

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

Reid, Thanks! You were right! Changing the code to: float (*theF)(float) = (float (*)(float)) EE -> getPointerToFunction(f); float retVal = theF(arg1); made the difference. Now it is dozens of times faster! I don't really understand the cause though.. Why doesn't ExecutionEngine cope well with "define float @someFunc(float %x)" and needs this trick ? (but copes well with

Probably because the integer version of the prototype is special-cased. The problem is that the JIT has a C function pointer of an arbitrary type that it only finds out about at runtime. Normally, if you call a function pointer with a known type, your compiler will generate the proper calling code and allocate the arguments in registers or on the stack. However, doing that inside the JIT would

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

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:

Hello, can anyone help me calling native functions from LLVM-Bytecode functions run in the JIT? I have a program which creates an LLVM execution engine and adds modules and functions to it on the fly. I need to call some native functions of my program from bytecode functions which causes some troubles as it appears not to be documented. My test scenario works like the following: I have

Dear all, I hope you enjoy your christmas! Recently I started to play lli with bc. I found that the lli only calls the main() function in bc file and then does nothing before the main() function returns, which means that the JIT::runFunction() function is involved only once with the main() function in bc file. If this was true, then lli does not have any control to the execution of program.

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

On Mon, 9 Aug 2004, Reid Spencer wrote: > Attached are three files: "valery.cpp" which contains your original, "reid.cpp" > which contains corrections to most of the FIXME items and "diffs" which shows > the differences between them. The differences should be instructive on what to > do. You were really, really close .. just a few details changing. The

On Wed, Dec 30, 2009 at 7:53 PM, Heming Cui <heming at cs.columbia.edu> wrote: > Dear all, >      I hope you enjoy your christmas! Recently I started to play lli with > bc. I found that the lli only calls the main() function in bc file and then > does nothing before the main() function returns, which means that the > JIT::runFunction() function is involved only once with the

Valery, Attached are three files: "valery.cpp" which contains your original, "reid.cpp" which contains corrections to most of the FIXME items and "diffs" which shows the differences between them. The differences should be instructive on what to do. You were really, really close .. just a few details changing. The code in "reid.cpp" compiles but I

Hi, I am having some difficulties getting the LLVM JIT to resolve extern "C" functions which I have defined in source file and invoking them via EE::runFunction() after generating a Function prototype for it. Is this possible or do I need to generate a .so for my functions are link against it? Thanks in advanced, Carter. Sorry for the double post but apparently I mistakenly tagged