[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:50:09 PM
> Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()
> 
> On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow wrote:
> >
> >
> >
> >
> > ----- Original Message ----
> >> From: Kenneth Uildriks 
> >> To: Samuel Crow 
> >> Cc: OvermindDL1 ; LLVM Developers Mailing List 
> 
> >> 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.

Thanks Kenneth!

Our runtime library may be written in C or have C bindings of C++ so I'll keep in mind what you said.  The function pointers should all point to code that was generated by our language so that will simplify matters.

Thanks again,

--Sam