[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()

[Kenneth Uildriks]

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.