On Thu, 20 Jan 2022, Joseph Myers wrote:
> > The old formulation of the instructions were never ratified as a
> > RISC-V standard. I don't think we need to hamstring ourselves here by
> > assuming the possibility of their implementation.
>
> If you ignore the old version, then the instructions can unconditionally
> be used for the fminimum_num / fmaximum_num functions (which GCC doesn't
> support as built-in functions at present) - but can't be used for the fmin
> / fmax functions if flag_signaling_nans.
Fair enough, thank you for your detailed explanation of the requirements
set by the individual revisions of the relevant standards, very valuable.
I think we have consensus that we can ignore pre-r2.2 hardware. What we
actually support is `-misa-spec=<2.2|20190608|20191213>', so we can assume
r2.2 semantics as the absolute minimum, matching the description in my
submission.
Also GCC documents IEEE 754-2008 semantics for the `fmin' and `fmax' RTL
operations:
"'fminM3', 'fmaxM3'
IEEE-conformant minimum and maximum operations. If one operand is
a quiet 'NaN', then the other operand is returned. If both
operands are quiet 'NaN', then a quiet 'NaN' is returned. In the
case when gcc supports signaling 'NaN' (-fsignaling-nans) an
invalid floating point exception is raised and a quiet 'NaN' is
returned."
and I think they need to stay as they are for the sake of IEEE 754-2008
hardware and the `minNum' and `maxNum' (`fmin'/`fmax') operations.
Looking further r20190608 of the RISC-V ISA specification then has[1]:
"Defined the signed-zero behavior of FMIN.fmt and FMAX.fmt, and changed
their behavior on signaling-NaN inputs to conform to the minimumNumber and
maximumNumber operations in the proposed IEEE 754-201x specification."
and specifically[2]:
"Floating-point minimum-number and maximum-number instructions FMIN.S and
FMAX.S write, respectively, the smaller or larger of rs1 and rs2 to rd.
For the purposes of these instructions only, the value -0.0 is considered
to be less than the value +0.0. If both inputs are NaNs, the result is
the canonical NaN. If only one operand is a NaN, the result is the
non-NaN operand. Signaling NaN inputs set the invalid operation exception
flag, even when the result is not NaN."
So for forwards compatibility of software built for r2.2 (such that it
continues producing correct results with r20190608+ hardware) I think we
need to provide `fmin'/`fmax' insns iff !HONOR_SNANS while keeping
`smin'/`smax' insns intact.
Then once we have IEEE 754-2019 support in place, which will require new
RTL standard pattern names, say `fminimum'/`fmaximum', we will provide
them iff (!HONOR_SNANS || riscv_isa_spec >= ISA_SPEC_CLASS_20190608). It
may be a good idea to start adding IEEE 754-2019 support, including the
relevant `__builtin_fminimum' and `__builtin_fmaximum' intrinsics, once
the GCC 13 development cycle has started.
I'll post v2 then according to this consideration, once it's gone through
regression testing. Thanks for your input again.
References:
[1] "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA",
Document Version 20190608-Base-Ratified, June 8, 2019, "Preface",
p. ii
[2] same, Section 11.6 "Single-Precision Floating-Point Computational
Instructions", p. 66
Maciej
