[llvm-commits] [llvm] r55807 - in /llvm/trunk: lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/2007-08-13-SpillerReuse.ll test/CodeGen/X86/2008-02-22-ReMatBug.ll test/CodeGen/X86/coalescer-commute3.ll test/Cod

[Evan Cheng]

On Sep 22, 2008, at 9:20 AM, Arnold Schwaighofer wrote:

>
>
>> However, isn't the plan to eventually remove -tailcallopt, enabling  
>> it
>> all the time?
> The last time (a while ago :) i checked (by running the testsuite) the
> performance was worse. There could be 4 reasons.
> 1.) fastcc + -tailcallopt results in an additional 'subl %esp
> ncallee_pops_arg_cnt' after every call site.
>  (if you have a sequence of tailcalls this is not bad since you pay
> only for the first call, but if all calls are normal calls this might
> get expensive)
> 2.) fastcc + -tailcallopt passed no arguments in registers while
> fastcc without -tailcallopt enabled did

I don't think that was the case. For whatever the reason, fastcc was  
not passing arguments in registers. I fixed that recently.


>
> 3.) due to lowering of arguments onto the callers arguments additional
> moves to the stack might be introduced.
> 4.) something else i have not thought of ;)
>
> When i did the performance testing i tried another version where only
> sibling tail calls were optimized so i could follow a caller pops
> arguments convention and performance still was worse compared to when
> -tailcallopt was disabled. Whether and why i didn't think of 2 and the
> obvious solution i don't remember. I guess i will do another round of
> testing. To see what happens now e.g after
> <http://llvm.org/viewvc/llvm-project?rev=56436&view=rev>.

Thanks.

Evan

>
>
> regards
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits