search for: getpointertofunct

...(I think my question is also somewhat more general in the sense how does any JIT system translate some form of low level IR (which presumably is JIT's data) into native code which is actually made executable at runtime). Specifically, in the following code snippet (from the tutorial), how does getPointerToFunction() actually generate native code for function LF and the call to FP succeed as if FPtr was a pointer to statically compiled code ? // JIT the function, returning a function pointer. void *FPtr = TheExecutionEngine->getPointerToFunction(LF); // Cast it to the right type (takes no arguments, r...

Yesterday I realised that if a Function has the calling convention set to "fast", then it is a bad idea to call it through the function pointer one gets from ExecutionEngine::getPointerToFunction(). The problem is that when calling it from my C++ program, the call will be made C-style, while the function expects to be called the fastcc way. Could LLVM either warn the user of this, or solve it for the user? One approach would be that getPointerToFunction() asserts that the function h...

...of the parent... On Thu, Nov 19, 2009 at 4:49 AM, Hans Wennborg <hans at hanshq.net> wrote: > Yesterday I realised that if a Function has the calling convention set > to "fast", then it is a bad idea to call it through the function pointer > one gets from ExecutionEngine::getPointerToFunction(). > > The problem is that when calling it from my C++ program, the call will > be made C-style, while the function expects to be called the fastcc way. > > Could LLVM either warn the user of this, or solve it for the user? > > One approach would be that getPointerToFunction...

Hi! I have this scenario: executionEngine->getPointerToFunction fails because a symbol can not be resolved. What can I do to catch this error? is an exception thrown? currently the program simply exits. returning NULL would be ok too. -Jochen

----- Original Message ---- > From: OvermindDL1 <overminddl1 at gmail.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 6:12:47 AM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > Er... Sending this to the list instead of the parent... > > On Thu, Nov 19, 2009 at 4:49 AM, Hans Wennborg wrote: > > Yesterday I realised that if a Function has the calling convention set > > to "fast", then it is a bad idea to call it through the funct...

Hans Wennborg wrote: > Yesterday I realised that if a Function has the calling convention set > to "fast", then it is a bad idea to call it through the function pointer > one gets from ExecutionEngine::getPointerToFunction(). > > The problem is that when calling it from my C++ program, the call will > be made C-style, while the function expects to be called the fastcc way. > > Could LLVM either warn the user of this, or solve it for the user? > > One approach would be that getPointerToFunction...

Can you be more precise about where the error occurs? Depending on where it is, LLVM may or may not be able to propagate the error safely. Reid On Tue, Oct 26, 2010 at 4:05 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > I have this scenario: > executionEngine->getPointerToFunction fails because a symbol can not be > resolved. > > What can I do to catch this error? is an exception thrown? currently the > program simply > exits. returning NULL would be ok too. > > -Jochen > > _______________________________________________ > LLVM Developers mai...

...(I think my question is also somewhat more general in the sense how does any JIT system translate some form of low level IR (which presumably is JIT's data) into native code which is actually made executable at runtime). Specifically, in the following code snippet (from the tutorial), how does getPointerToFunction() actually generate native code for function LF and the call to FP succeed as if FPtr was a pointer to statically compiled code ? // JIT the function, returning a function pointer. void *FPtr = TheExecutionEngine->getPointerToFunction(LF); // Cast it to the right type (takes no arguments, r...

...! Thanks. >> >> Just to clarify things: on my end, it doesn't really matter what is the >> default behavior, as long as vmkit can continue to have the existing >> behavior of lazy compilation. With Chris' solution, I was wondering how you >> would implement the getPointerToFunction{Eager, Lazy} functions when the >> getPointerToFunction is called by the JIT, not the user. For example, when >> Function F calls Function G and the JIT needs an address for G (either a >> callback or the function address), how will it know if it must call >> getPointerTo...

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the heap), do I still need 'exec'? Deleting it immediately after use seems to have no adverse effect. I j...

...gt; Just to clarify things: on my end, it doesn't really matter what is the >>>> default behavior, as long as vmkit can continue to have the existing >>>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>>> getPointerToFunction is called by the JIT, not the user. For example, when >>>> Function F calls Function G and the JIT needs an address for G (either a >>>> callback or the function address), how will it know if it must ca...

...t; >>> Just to clarify things: on my end, it doesn't really matter what is the >>> default behavior, as long as vmkit can continue to have the existing >>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>> getPointerToFunction is called by the JIT, not the user. For example, when >>> Function F calls Function G and the JIT needs an address for G (either a >>> callback or the function address), how will it know if it must call >>&...

...I think differences are within the margin or error. level user time 0 17339ms 1 16913ms 2 16891ms 3 16898ms Level is set with builder->setOptLevel(olev); Compilation time is excluded by taking the only top-level function address before the run with getPointerToFunction. So I measure time without getPointerToFunction. Why optimization almost doesn't speed it up? What are the other than setOptLevel ways to control optimization? My mindset is defined by experience with gcc, when increasing inlining levels speeds the code up significantly. Does JIT inline...

...il.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent: Thu, November 19, 2009 12:22:55 PM >> Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() >> >> > I agree with you OvermindDL1, >> > >> > SInce the language I'm going to be working on doesn't support varargs, it >> would be nice to be able to ditch the C calling convention for fastcc in all >> occurrances for an added speed boost...

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also invalidates the code cache. Even so, this will likely only work in cases where code generation is only invoked...

...ennethuil at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 12:22:55 PM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > > I agree with you OvermindDL1, > > > > SInce the language I'm going to be working on doesn't support varargs, it > would be nice to be able to ditch the C calling convention for fastcc in all > occurrances for an added speed boost. I also will need t...

...hment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding MCJIT in this mailing list, and I understand it that MCJIT currently cannot be used in the same way as JIT. The separate function-by-function (i.e. incremental) compilation approach with getPointerToFunction, like the one used in the Kaleidoscope tutorial, will not work. Is this correct or do I do something wrong in my code ? There was also a discussion about using multi-module approach instead of getPointerToFunction, but it seems that support for this is not yet available. I would like to kno...

> I agree with you OvermindDL1, > > SInce the language I'm going to be working on doesn't support varargs, it would be nice to be able to ditch the C calling convention for fastcc in all occurrances for an added speed boost.  I also will need to add my own library calling convention on one platform I plan on supporting which will be register-loaded as well. Are you going to be

On Nov 19, 2009, at 10:20 PM, Nick Lewycky wrote: > > Sure. You could be passing it in as a function pointer to another > function, that's planning to call it with fastcc calling convention. > > Or worse, you might be planning to call it with _stdcall (say, on > Windows) and discarding the calling convention would be actively harmful. > > In other words, please

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the case of the new MCJIT engine, the JITMemoryManager is owned by the MC...