[LLVMdev] RFC: Tail call optimization X86

Arnold Schwaighofer arnold.schwaighofer at gmail.com
Fri Oct 5 11:48:02 PDT 2007


well then back to my original question? evan? chris?
On 5 Oct 2007, at 19:41, Evan Cheng wrote:
> We can set a policy of treating fastcc external functions
> as c functions. Then there is no chance of introducing ABI
> incompatibility.
this means limiting tail call opt to protected/invisible functions  
within a module?
a little limiting i think.

but i think if the incompatibility between modules compiled with  
tailcallopt on/off is documented
then this will be okay?
and this would only happen if someone other than llvm-gcc used llvm  
as a backend
anyway.

so i will make tailcallopt toggle the stack adjusting behaviour. with  
llvm-gcc this won't be a problem
and if someone other using llvm as a backend runs into a problem than  
there is the documentation
and the maillist that will help.

is that okay?

On 5 Oct 2007, at 20:46, Chris Lattner wrote:

> On Fri, 5 Oct 2007, Arnold Schwaighofer wrote:
>>> to me like llvm-gcc honors that.  Certainly it should.
>>
>> This would imply one fastcc abi (callee pops args on return) to rule
>> them all?
>> That is only if fastcall translates to llvm fastcc  of course.
>
> fastcall != fastcc.  fastcall is a well defined convention on x86  
> that has
> very specific ABI requirements.  fastcc, on the other hand, is an LLVM
> thing, and LLVM is allowed to "innovate" on the abi where it wants to.
>
> There is no requirement for LLVM to handle fastcc and fastcall the  
> same.
>
okay
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list