Re: PATCH [3/n] X32: Promote pointers to Pmode

["H.J. Lu" <hjl dot tools at gmail dot com>]

Hi Richard,

Is my patch OK?

Thanks.


H.J.
----
On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <rth@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.
>