llvm dev - Nov 2006 - [LLVMdev] I want to do something moderately insane, please help!

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 and/or link with external code. I currently expose some 
functions from the code being checked that allow you to slot in your own 
thread management, but I need this to be as fast as possible because it 
gets called a *lot*. I have managed OK with simply exposing a function 
and jitting it, then calling it through the runFunction member of the 
Jitter class, which works fine but seems a little slow. How feasible 
would it be to get at the underlying function pointer directly, seeing 
as the type signature is well-known in advance, then just calling it 
with a normal C-style call to a function pointer, e.g. (*compfn)(a,b).

Yes, this is all a bit nuts, and yes, it's not really how either the 
interpreter or the jitter was meant to be used, but if I can make this 
particular trick work, it will significantly speed up the model checker, 
particularly since I'll be able to use it for a few other things too.

Thanks,
Sarah

Sarah Thompson wrote:
> 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 and/or link with external code. I currently expose some 
> functions from the code being checked that allow you to slot in your own 
> thread management, but I need this to be as fast as possible because it 
> gets called a *lot*. I have managed OK with simply exposing a function 
> and jitting it, then calling it through the runFunction member of the 
> Jitter class, which works fine but seems a little slow. How feasible 
> would it be to get at the underlying function pointer directly, seeing 
> as the type signature is well-known in advance, then just calling it 
> with a normal C-style call to a function pointer, e.g. (*compfn)(a,b).
>
> Yes, this is all a bit nuts, and yes, it's not really how either the 
> interpreter or the jitter was meant to be used, but if I can make this 
> particular trick work, it will significantly speed up the model checker, 
> particularly since I'll be able to use it for a few other things too.
>
>   
OK, I've answered my own question. What you need to do is export an 
initialisation function that returns a function pointer. You jit the 
initialisation function (by calling it), which also causes the 
address-taken function to be jitted. When you get the pointer back, 
*that* pointer can be called directly from C++, with no performance 
penalty. I think I'll be using this trick quite a bit.

Sarah

On Wed, 29 Nov 2006, Sarah Thompson wrote:
> Sarah Thompson wrote:
>> Yes, this is all a bit nuts, and yes, it's not really how either
the
>> interpreter or the jitter was meant to be used, but if I can make this
I welcome moderate insanity :)
> OK, I've answered my own question. What you need to do is export an
> initialisation function that returns a function pointer. You jit the
> initialisation function (by calling it), which also causes the
> address-taken function to be jitted. When you get the pointer back,
> *that* pointer can be called directly from C++, with no performance
> penalty. I think I'll be using this trick quite a bit.
It should be easier than that: instead of calling runFunction, just call 
EE->getPointerToFunction and cast the return pointer to be the appropriate 
function pointer.  getPointerToFunction will cause the function to be 
immediately compiled, and the function pointer is valid unless you 
explicitly release the code.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/