search for: runfunctions

I noticed that runFunction (for MCJIT) is very limited. At the same time the interpreter already has a fairly generic way of calling functions from a pointer and a Function * (for description) using libffi. Would it make sense to pull that functionality out into a small support library and using it in MCJIT? As is runFunction isn't particularly usable. -- Johannes S. Mueller-Roemer, MSc Wiss.

How can I properly exit from code being executed via "ExecutionEngine::runFunction"? My JIT'd code is executing and it calls a function in the host program. This host function then decides the executing code should be stopped and wants to return from runFunction. I've considered setjmp/longjmp, but I'm not sure if this would properly clean up the ExecutionEngine internals.

On Jan 29, 2013, at 21:41 , edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > How can I properly exit from code being executed via > "ExecutionEngine::runFunction"? My JIT'd code is executing and it calls > a function in the host program. This host function then decides the > executing code should be stopped and wants to return from runFunction. If the executing

My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to dispatch_async() never gets called. The async block is supposed to call a function pointer callback that was passed in to decode(). Everything is being called on the main

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

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

I have used libdispatch (on FreeBSD) from JIT'd code without any issues, so I think your bug is elsewhere. David On 30 Jan 2013, at 07:43, Rick Mann wrote: > My host app calls runFunction() on my JITed code. It, in turn, calls a C function ("decode()") in the host app that then calls dispatch_async(). The runFunction() call returns as expected, but the block passed to

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

On Tue, 12 Jun 2007, Jan Rehders wrote: >> Jan, how are you doing this? Are you creating an external LLVM >> Function object named "get5", then using EE::addGlobalMapping? If >> 'get5' exists in the address space, why not just let the JIT resolve it >> (which will then create the stub)? > > Yes. I create a Function with matching signature,

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

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

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

What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. -------------- next part -------------- An HTML attachment was

I wish to run a function passing in an int value of 5 as a single parameter. can you please complete the code as all the examples I can find are old. llvm::Function *EntryFn = Mod->getFunction("createModule"); if (!EntryFn) { return 255; } else { EE->runFunction(EntryFn, ???????); } Thank you! -- View this message in context:

"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

On 30/01/13 07:17, Rick Mann wrote: > If the executing code wants to return, it should just return. I take > it that doesn't work for you? You probably need to modify things so > that your JITed code can tolerate the host code returning, or it can > return some kind of error condition. The guest code in this case doesn't know that it will be returning. This "abort"

Hi, I'm using LLVM 2.4 (but llvm-gcc 2.2) on Ubuntu 8.10 (Intrepid Ibex) for a small part-time project combining Witty (http://www.webtoolkit.eu) and the ExecutionEngine in LLVM. (This is my second week with any of these so I still lack a lot of basic knowledge.) Sometimes I want to call a function returing a struct (in this case std::string), thus hasStructRetAttr() is true for the Function

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

I'm starting to work with custom types and wondering how I can pass/return them via the ExecutionEngine? runFunction returns only a GenericValue, so it appears somehow I must make use of its pointer member. For example, how do call this function/type: %struct.mine = type { i32, i8, float, double } define void @make_struct(%struct.mine* noalias sret %agg.result, i32 %a, i8 signext %b) --