On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <r...@redhat.com> wrote:
> On 07/10/2011 03:01 PM, H.J. Lu wrote:
>> We only want to promote function parameters passed/returned in register.
>> But I can't tell if a value will be passed in register or memory inside of
>> TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't
>> promote. Even if we don't promote it explicitly, hardware still zero-extends
>> it for us. So it isn't a real issue.
>
> The hardware *usually* zero-extends. It all depends on where the data is
> coming from. Without certainty, i.e. actually representing it properly,
> you're designing a broken ABI.
>
> What you wrote above re T_F_V not being able to tell register or
> memory doesn't make sense. Did you really mean inside
> TARGET_PROMOTE_FUNCTION_MODE?
> And why exactly wouldn't you be able to tell there? Can you not find out
> via a call to ix86_return_in_memory?
>
TARGET_PROMOTE_FUNCTION_MODE is for passing/returning
value in a register and the documentation says that:
FOR_RETURN allows to distinguish the promotion of arguments and
return values. If it is `1', a return value is being promoted and
`TARGET_FUNCTION_VALUE' must perform the same promotions done here.
If it is `2', the returned mode should be that of the register in
which an incoming parameter is copied, or the outgoing result is
computed; then the hook should return the same mode as
`promote_mode', though the signedness may be different.
But for TARGET_FUNCTION_VALUE, there is no difference for
register and memory. That is why I don't promote when
FOR_RETURN is 1. mmix/mmix.c and rx/rx.c have similar
treatment.
--
H.J.
