llvm dev - Nov 2009 - [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 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.

----- Original Message ----
> From: Kenneth Uildriks <kennethuil 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 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.
Hello Kenneth,

I'd like to be able to call the generated bitcode from lli as well as opt
and then llc.  I'm not sure that counts.

All of the code would be generated internally to the language my team is going
to be working on.  Our langauge is extensible so we'll be adding to the
syntax more often than to the linked bitcodes but definitely varargs will not be
added.  The first draft of all of the generated bitcode is translated to LLVM
Assembly by LLVM-GCC but we will be hand-tuning the code to make it
endian-neutral and hope to make it platform-agnostic bitcode as well.

Does that explain what we're trying to do?

--Sam

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com>
wrote:
>
>
>
>
> ----- Original Message ----
>> From: Kenneth Uildriks <kennethuil 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 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.
>
> Hello Kenneth,
>
> I'd like to be able to call the generated bitcode from lli as well as
opt and then llc.  I'm not sure that counts.
>
> All of the code would be generated internally to the language my team is
going to be working on.  Our langauge is extensible so we'll be adding to
the syntax more often than to the linked bitcodes but definitely varargs will
not be added.  The first draft of all of the generated bitcode is translated to
LLVM Assembly by LLVM-GCC but we will be hand-tuning the code to make it
endian-neutral and hope to make it platform-agnostic bitcode as well.
>
> Does that explain what we're trying to do?
So you won't be calling it from C++ code?

If a function's callers are all implemented in your language, then the
function can have the fastcc convention and all calls to it can also
use the fastcc convention.  (Calls have to have the same calling
convention as callees).  If you have code in your language that JITs
the function in question and gets a function pointer, it can make the
call through that function pointer with the fastcc convention as well
if the target function has the fastcc convention.

If you try to call it through the function pointer from C++, however,
you'll need the target of that call to have the C calling convention.
In that case, a helper function for use from C++ code is your best
bet.