On Tue, Jul 11, 2023 at 09:50:23AM +0200, Jan Beulich via Gcc-patches wrote:
> > Quote from what Jakub said in [1].
> > -------
> > This is not correct.
> > While using such code for _mm_cvtsbh_ss is fine if it is documented not to
> > raise exceptions and turn a sNaN into a qNaN, it is not fine for HONOR_NANS
> > (i.e. when -ffast-math is not on), because a __bf16 -> float conversion
> > on sNaN should raise invalid exception and turn it into a qNaN.
> > We could have extendbfsf2 expander that would FAIL; if HONOR_NANS and
> > emit extendbfsf2_1 otherwise.
> > -------
> > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607108.html
>
> I'm not sure I understand: It sounds like what Jakub said matches my
> observation, yet then it seems unlikely that the issue wasn't fixed in
> over half a year.
>
> Also having the expander FAIL when HONOR_NANS (matching what I was
> thinking) still doesn't clarify to me what then would happen to uses of
> the builtin. Is there any (common code) fallback for such a case? I
> didn't think there would be, in which case wouldn't this result in an
> internal compiler error?
There is some bfloat specific generic code I've added last year in expr.cc
and optabs.cc:
grep arm_bfloat_ *.cc
expr.cc: || (REAL_MODE_FORMAT (from_mode) ==
&arm_bfloat_half_format
expr.cc: || (REAL_MODE_FORMAT (to_mode) ==
&arm_bfloat_half_format
expr.cc: if (REAL_MODE_FORMAT (from_mode) == &arm_bfloat_half_format
expr.cc: && REAL_MODE_FORMAT (to_mode) == &arm_bfloat_half_format
optabs.cc: == &arm_bfloat_half_format
optabs.cc: == &arm_bfloat_half_format
optabs.cc: if (REAL_MODE_FORMAT (GET_MODE (from)) == &arm_bfloat_half_format
plus if that doesn't trigger there are libcalls for it in libgcc, e.g.
libgcc/soft-fp/extendbfsf2.c
The generic code ensure one doesn't need full set of library functions
like also extendbf{d,x,t,h}f2.c etc. when target has next to bfloat also
IEEE single support.
The generic code also uses shifts when not honoring NaNs (etc.) where
possible, but of course target code can override it if it can do the stuff
better than the generic code, I just wanted some fallback because
on targets which do support bfloat and IEEE single the shifts will be a
common way to extend.
Jakub
