llvm dev - Mar 2011 - [LLVMdev] Calls to functions with signext/zeroext return values

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote:
> Promoting the return value is unsafe for bool returns on x86-64, which in
the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit
register are 0.
My comment is a bit off, because the question of what type to make the return
value is somewhat orthogonal to the question of which zext assert we should add.

Cameron

On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at apple.com>
wrote:
> On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote:
>
>> Promoting the return value is unsafe for bool returns on x86-64, which
>> in the latest revision of the ABI only guarantees that the top 7 bits
of
>> the 8-bit register are 0.
>
> My comment is a bit off, because the question of what type to make
> the return value is somewhat orthogonal to the question of which zext
> assert we should add.
I'm not sure I follow. Won't a zeroext attribute on a bool return
value ensure that it will be zero-extended to 32 bits by the callee?
Or does the X86 backend consider such functions unlowerable (via
TargetLowering::CanLowerReturn()) and thereby bypass the extension to
32 bits in SelectionDAGBuilder::visitRet() making a promotion in the
caller unnecessary?

-Ken

On Mar 16, 2011, at 11:43 AM, Ken Dyck wrote:
> On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at
apple.com> wrote:
>> On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote:
>> 
>>> Promoting the return value is unsafe for bool returns on x86-64,
which
>>> in the latest revision of the ABI only guarantees that the top 7
bits of
>>> the 8-bit register are 0.
>> 
>> My comment is a bit off, because the question of what type to make
>> the return value is somewhat orthogonal to the question of which zext
>> assert we should add.
> 
> I'm not sure I follow. Won't a zeroext attribute on a bool return
> value ensure that it will be zero-extended to 32 bits by the callee?
> Or does the X86 backend consider such functions unlowerable (via
> TargetLowering::CanLowerReturn()) and thereby bypass the extension to
> 32 bits in SelectionDAGBuilder::visitRet() making a promotion in the
> caller unnecessary?
The X86 backend currently zero-extends them to 32 bits, but according to the ABI
it need only zero-extend them to 8 bits. I'm going to change this in a few
minutes to expose some additional optimization opportunities.

Cameron