llvm dev - Nov 2009 - [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 <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() asserts that the
> function has default calling convention. This way, the user would be
> alerted.
>
> Another approach would be that if getPointerToFunction() detects that
> the function does not have default calling convention, it produces a
> wrapper function, and returns a pointer to that.
>
> My question is, is there code that would get into trouble because of
> this?
>
> For example, someone who is aware of this might be doing inline asm to
> produce a fastcc call through the pointer.
>
> Or, someone might rely on the function actually being located on the
> returned address, and not necessarily calling it. This would break if
> the address to the wrapper is returned instead.
>
> Any thoughts on this?
>
> On a side note: wouldn't it be nice if the VerifierPass checks that
> calling conventions on calls and functions in a module match up?
I would prefer them to remain fastcc if I specify them as fastcc as I
actually do have 'event' handlers passed as fastcc to my C++ code
before being passed back into the JIT as another function parameter so
it can call it as fastcc internally.  If someone is getting a pointer
to a function, they should know about calling conventions anyway.

----- 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
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 has default calling convention. This way, the user would be
> > alerted.
> >
> > Another approach would be that if getPointerToFunction() detects that
> > the function does not have default calling convention, it produces a
> > wrapper function, and returns a pointer to that.
> >
> > My question is, is there code that would get into trouble because of
> > this?
> >
> > For example, someone who is aware of this might be doing inline asm to
> > produce a fastcc call through the pointer.
> >
> > Or, someone might rely on the function actually being located on the
> > returned address, and not necessarily calling it. This would break if
> > the address to the wrapper is returned instead.
> >
> > Any thoughts on this?
> >
> > On a side note: wouldn't it be nice if the VerifierPass checks
that
> > calling conventions on calls and functions in a module match up?
> 
> I would prefer them to remain fastcc if I specify them as fastcc as I
> actually do have 'event' handlers passed as fastcc to my C++ code
> before being passed back into the JIT as another function parameter so
> it can call it as fastcc internally.  If someone is getting a pointer
> to a function, they should know about calling conventions anyway.
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.

--Sam Crow

> 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 calling the JITted function from C++, or from your language?

If the former, you'll need the function you're calling from C++ to
have a calling convention that C++ understands.  You could always
write a helper function with the C calling convention that does
nothing but call the real function which has the fastcc convention.
Of course this would only give you a performance win if the real
target function is also called from other JITted code, or if it's
written out to bitcode and llc'd later with calls into it from other
bitcode.