On Mon, 24 Jan 2022, Joseph Myers wrote: > > 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. > > Where, to repeat the point about possibly confusing version numbers, > that's saying we can ignore hardware from before *ISA* revision 2.2 (which > contained 'F' and 'D' extension version 2.0) - not that we can ignore > hardware from before 'F' and 'D' extension version 2.2 (which changed the > semantics of the FMIN and FMAX instructions).
OK, I'll try to make it clear in the change description of v2. > > 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. > > The newer instruction semantics correspond to the functions fminimum_num > and fmaximum_num, not fminimum and fmaximum (which are functions that > treat both quiet and signaling NaNs like most libm functions do - any > argument a NaN means the result is NaN). I got these wrong then, sorry. I got lost too: what is the difference between `fmin'/`fmax' and `fminimum'/`fmaximum' then? It looks to me like we have a zoo of selection functions now with very subtle differences between each other. Maciej
