[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

[Chris Lattner]

On Sep 22, 2008, at 2:31 AM, Arnold Schwaighofer wrote:

> On Mon, Sep 22, 2008 at 9:54 AM, Duncan Sands <baldrick at free.fr>  
> wrote:
>>>> Does this mean that "PerformTailCallOpt" changes the ABI?
>>
>> Arnold already agreed that tailcall could use the new calling  
>> convention,
>> i.e. be the same as fastcc.

> BUT there still is an ABI difference when -tailcallopt is enabled.

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

Front-end authors that are using this should know that -tailcallopt  
affects the fastcc ABI and not use it if possible.

However, isn't the plan to eventually remove -tailcallopt, enabling it  
all the time?

-Chris