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
