Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Sep 12, 2022 at 07:36:05PM +0000, Joseph Myers wrote:
> On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> 
> > Now, I guess for the fixincludes it could also use
> > #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
> > where earlier GCC 13 snapshots would not be doing the fixincludes,
> > but the question is what to use for upstream glibc, because
> > there will be 13.0 snapshots where C++ doesn't support _Float{16,32,64,128}
> > and where it is essential to use what glibc has been doing previously
> > and using the #else would fail miserably, and then 13.0 snapshots where it
> > does support it and where using the if would fail miserably.
> 
> We don't claim in glibc to support old snapshots from master, so checking 
> for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is 
> fine.

Ok, makes sense, especially if it is applied on the glibc side a few months
after it is changed on the GCC side.  If it is applied immediately, there
could be people who have 2 weeks old GCC trunk snapshot and try it with latest
glibc, but if it will be say in December, it will be far less likely.

> > Conversion from BFmode to SFmode is easy, left shift by 16 and ought to be
> > implemented inline, SFmode -> BFmode conversion is harder,
> 
> Properly the right way for converting from BFmode to SFmode in the 
> presence of -fsignaling-nans should depend on how the result is used.  If 
> it's used for arithmetic, it's OK to have converted a BFmode signaling NaN 
> to an SFmode signaling NaN, but if e.g. the result is examined with 
> issignaling or otherwise stored so it may be significant later whether the 
> result is a quiet or signaling NaN, IEEE semantics would mean a signaling 
> NaN should be a converted to a quiet NaN with "invalid" raised.  Though I 
> don't know how far hardware instructions for BFmode attempt to follow IEEE 
> semantics.
> 
> (Cf. powerpc single-precision load instructions whose effect is defined as 
> a purely bitwise conversion from single to double precision, so that 
> single-precision load and store of a signaling NaN never end up converting 
> it to a quiet NaN even though the in-register format is double precision.)

Looking at HW instructions, I believe x86 F16C VCVTPH2PS and VCVTPS2PH
raise invalid on SNaN and turn it into QNaN and from what I can understand,
the AVX512F16 conversion insns like VCVTSH2SS and VCVTSS2SH do too,
but AVX512_BF16 VCVTNE2PS2BF16 doesn't raise any exceptions (and there is
no insn for the other direction).

> > (untested) and the question is if it should be implemented in libgcc
> > (and using soft-fp or not), or inline, or both depending on -Os.
> 
> Also if you try to do a direct conversion between BFmode and HFmode, 
> soft-fp's current support for conversions may not handle that case (where 
> one type has wider exponent range and other type has higher precision).

Can't that be implemented as 2 conversions, convert BFmode to SFmode and
then back to HFmode (or the other way around)?
SFmode is a superset of both formats, so except for the raise exception on
SNaN and conversion to QNaN extension to SFmode from both formats should be
lossless?

In any case, the bfloat16 support is intended maybe for follow-up patches,
not in this patch.

	Jakub