[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

[Evan Cheng]

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.

Evan

> 
> In this code, with a direct call:
> 
> declare signext i16 @foo(i32) nounwind
> 
> define signext i16 @t7() nounwind {
> entry:
>  %0 = tail call signext i16 @foo(i32 0) nounwind
>  ret i16 %0
> }
> 
> LLVM without the tailcall optimization emits this:
> 
> 	callq	_foo
> 	movswl	%ax, %ecx
> 
> This means that even though the return types and attributes
> match, CodeGen still believes it needs to do caller-side sign
> extension. I don't know the details of why that is, but it
> says that it's not safe to do a tail call with a  signext
> return attribute, regardless of what the callee is.
> 
> The same appears to apply to the zeroext attribute also.
> 
> Also, I've confirmed that GCC also uses caller-side casts and
> suppresses tail calls for both signed short and unsigned short.
> 
> Dan
>