[llvm-commits] [llvm] r95195 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp lib/Target/X86/X86ISelLowering.cpp test/CodeGen/X86/tailcall2.ll test/CodeGen/X86/tailcallfp2.ll

[Dan Gohman]

On Feb 3, 2010, at 11:36 AM, Evan Cheng wrote:

> 
> On Feb 3, 2010, at 11:33 AM, Evan Cheng wrote:
> 
>> 
>> On Feb 3, 2010, at 11:13 AM, Dan Gohman wrote:
>> 
>>> 
>>> On Feb 2, 2010, at 7:28 PM, Evan Cheng wrote:
>>> 
>>>> Author: evancheng
>>>> Date: Tue Feb  2 21:28:02 2010
>>>> New Revision: 95195
>>>> 
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=95195&view=rev
>>>> Log:
>>>> Allow all types of callee's to be tail called. But avoid automatic tailcall if the callee is a result of bitcast to avoid losing necessary zext / sext etc.
>>> 
>>> Hi Evan,
>>> 
>>> I believe the real problem here is not bitcasted callees (which
>>> can't be reliably detected, since the bitcast could happen in code
>>> that isn't visible to the compiler). I believe the real problem
>>> here is with the signext attribute.
>> 
>> Yes I am aware this is one of the issues (it caused miscompilation of llvm Module.cpp and others). For now, I think it makes sense to avoid tail calling these because the we can't reasonable claim the caller / callee signatures would match when a bitcast is involved.
> 
> Oh you mean we should disable tailcall opt when either the caller or callee result is sext / zext.
> 
> Right now we allow tailcall opt when their attributes match. If the calling conventions match I don't see why that's not sufficient. Certainly I am not seeing any evidence that's a problem yet.

Both GCC and llvm-gcc emit an explicit sign-extend in the caller for this C code
on x86-32 and x86-64.

short foo(void);
short bar(void) { return foo(); }

Also, GCC declines the tailcall optimization for this code.

Dan