[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

[Arnold Schwaighofer]

On Mon, Sep 22, 2008 at 5:50 PM, Chris Lattner <clattner at apple.com> wrote:
>> So in cases where a library would be compiled with -tailcallopt
>> enabled and a the program using the library would be compiled without
>> -tailcallopt all hell would break loose.
>
> After sleeping on it, I think that this is actually ok.  We reserve
> the right to change the 'fastcc' ABI across LLVM releases anyway,
> which means that it isn't a stable thing that people can depend on.
> The optimizers only introduce it when it knows all callers of a
> function, thus it should be safe to do whatever we want within a
> model, so long as it is consistent within that module.
Yes after thinking about it i remembered that i brought this problem
up when i first introduced -tailcallopt and something along the lines
of the above was the conclusion.
> Front-end authors that are using this should know that -tailcallopt
> affects the fastcc ABI and not use it if possible.
Yes maybe i should add this somewhere to the documentation.
<http://llvm.org/docs/CodeGenerator.html#targetimpls> might be a good
place. Stating something along the lines:

NOTE: If -tailcallopt is enabled the ABI of fastcc changes. Modules
compiled with -tailcallopt will not work together with modules
compiled without it.

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

regards