[LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()

[Samuel Crow]

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