On 2/9/22 21:12, Roger Sayle wrote:
This patch adds middle-end support for target ABIs that pass/return
floating point values in integer registers with precision wider than
the original FP mode. An example, is the nvptx backend where 16-bit
HFmode registers are passed/returned as (promoted to) SImode registers.
Unfortunately, this currently falls foul of the various (recent?) sanity
checks that (very sensibly) prevent creating paradoxical SUBREGs of
floating point registers. The approach below is to explicitly perform the
conversion/promotion in two steps, via an integer mode of same precision
as the floating point value. So on nvptx, 16-bit HFmode is initially
converted to 16-bit HImode (using SUBREG), then zero-extended to SImode,
and likewise when going the other way, parameters truncated to HImode
then converted to HFmode (using SUBREG). These changes are localized
to expand_value_return and expanding DECL_RTL to support strange ABIs,
rather than inside convert_modes or gen_lowpart, as mismatched
precision integer/FP conversions should be explicit in the RTL,
and these semantics not generally visible/implicit in user code.
Hi Roger,
I cannot comment on the patch, but I do wonder (after your "strange ABI"
comment): did we actively decide on (or align to) a register passing ABI
for HFmode, or has it merely been decided by the implementation of
promote_arg:
...
static machine_mode
promote_arg (machine_mode mode, bool prototyped)
{
if (!prototyped && mode == SFmode)
/* K&R float promotion for unprototyped functions. */
mode = DFmode;
else if (GET_MODE_SIZE (mode) < GET_MODE_SIZE (SImode))
mode = SImode;
return mode;
}
...
There may be a rationale why it's good to pass a HF as SI, but it's not
documented there.
Anyway, I checked what cuda does for HF, and it passes a byte array:
...
.param .align 2 .b8 _Z5helloPj6__halfs_param_1[2],
...
So, I guess what I'm saying is I'd like to understand why we're having
the HF -> SI promotion.
Thanks,
- Tom
