[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()

[Samuel Crow]

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