similar to: [LLVMdev] Unit testing with random input using JIT

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

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

There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145. Header is splited into two (OldPred->NewBB). Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB). I think it should be DT->splitBasicBlock(OldPred). When I tried to extract a code region whose header has 2 successors, my pass crashed. It was because header (or OldPred) is the

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 all, I have problem with ExtractCodeRegion (CodeExtractor.cpp). My original program is as follows. bb: ... %tmp.15 = load %struct.MYSQL_ROWS** %3, align 4 ... bb1: ... %tmp.1 = load %struct.MYSQL_ROWS** %6, align 4 ... bb4: ; preds = %bb1, %bb, %entry %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15, %bb ], [ %tmp.1, %bb1 ]

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

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

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, 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 all, I've written a small language implementation that JIT-compiles code prior to execution. At the moment, i execute the function through ExecutionEngine::runFunction. However, this requires me to keep all of the code generation artifacts (instructions, constants, etc) around during execution. Given that execution compiles the program down to machine code, is there a reasonably

Ó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, I'm current using LLVM 2.5 to JIT code in a event driven language running on a game engine. Haven't updated to 2.7 yet, but I do intend to. When checking for memory leaks I found that each time I was calling EE->runFunction after creating a stub function to execute an event, all the pass information was being repeatedly added to PMDataManager. I have changed addAnalysisImplsPair

"Kaylor, Andrew" <andrew.kaylor at intel.com> writes: > 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

I'm unfamiliar with the leak you've just described, but Jeffrey Yasskin has done a lot of work cleaning up leaks for 2.7 and trunk. I was just going to mention that unless the function you are calling via runFunction has a simple prototype that's special cased in runFunction, it will generate its own stub function for every call. If you don't want to worry about that, you can call

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64

> > ExecutionEngine* EE = ExecutionEngine::create( MP, true ); > > As Reid pointed out, changing true to false will get it to work. as I've posted already, I got Segmentation Fault. Now, i have re-compiled LLVM with debug support. The evaluation is broken at line 78 in file: lib/ExecutionEngine/JIT/JIT.cpp The assertion assert(ArgValues.size() == 1); fails. But

Hi, As some of you may remember, I'm implementing an LLVM-based model checker. I'm doing something a little odd, in that mostly I'm using the interpreter (currently a hacked version of lli with threads) for most things because I need to hook into lots of stuff that would be difficult to manage otherwise, but I'm also using the jitter for some things that need to be fast