On 3/14/2022 3:09 AM, Richard Biener wrote:
On Mon, 14 Mar 2022, Roger Sayle wrote:
I thought I'd add a few comments that might help reviewers of this patch.
Most importantly, this patch should be completely safe, as both changes
only trigger with FLOAT vs INT size mismatches which currently both ICE in
the compiler a few lines later. Admittedly, this indicates something odd
about a target's choice of ABI, but one alternative might be to issue a
"sorry, unimplemented" error message rather than ICE, perhaps with a
TODO or FIXME comment that support for mixed size FP/integer ABIs be
added in future.
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].
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.
I hope this helps. If folks could air their concerns out loud, I can try my
best
to address those worries.
First of all I'm not familiar with the ABI related code as all, so I
refrained from commenting. But now I've looked closer (still unfamiliar
code).
I suppose there's targets passing SFmode in a SImode GPR and DFmode
in a DImode GPR (all soft-float targets?), so that already works somehow.
Why does nvptx choose DImode for SFmode passing then? Can't it choose
(subreg:SI di:..) or so? Does it require zero-extending to DImode
on the caller side? It seems your expand_expr_real_1 code does
not rely on that? So, why does nvptx function_arg hook (?) insist
on returning a DImode reg for an SFmode argument rather than
an SImode subreg of that?
I think so. V850 for example might follow this pattern, but those
extensions came in after the original port, so I'm not 100% sure.
I'd hazard a guess DI is a better match than SI simply because nvptx is
a 64bit target. I'd be surprised if sign vs zero extension is actually
important. It may be following from existing conventions on the port.
jeff
