Re: PING**4 - [PATCH] middle-end: Support ABIs that pass FP values as wider integers.

[Jeff Law <jeffreyalaw@gmail.com>]

On 3/14/2022 2:39 AM, Roger Sayle wrote:
>
> The only (other?) possible point of contention is the (arbitrary) decision that
> when passing floating point values in a larger integer register, the code is
> hardwired to use zero-extension.  This in theory could be turned into a target
> hook to support sign-extension, but given these are padding bits, zero seems
> appropriate. [On x86_64, if passing DFmode argument in a V2DFmode vector,
> say, it seems reasonable to use movq and zero the high bits].
I'm not terribly concerned about the zero vs sign extension.

>
> The final point is that at the moment, the only affected target is nvptx-none,
> as I don't believe any other backend specifies an ABI that requires passing
> floating point values in wider integer registers.  Having said that, most targets
> don't yet support HFmode, and their ABI specifications haven't yet been
> updated as what to do in that eventuality.  If they choose to treat these like
> HImode, they'll run into the same issues, as most ABIs pass HImode in
> wider word_mode registers.
The plan for our target has been to pass around HFmode in the GPF 
registers, but in general HFmode is new enough that not many targets 
have them handled explicitly in their ABI.

Passing HFmode objects around in GPRs is odd, but not crazy so. We've 
certainly had targets where FP values would get passed around in the 
integer registers -- for example the 32 bit PA ABI mandated this kind of 
behavior in some circumstances.  Of course they also relied on the 
linker to look at the caller & callee and add a stub in between them to 
deal with mismatches :(

jeff