[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 12:07 PM, Dan Gohman wrote:

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

I know. The question is whether that's just a missed optimization?

Evan

> 
> Dan
>