[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