expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]

  Hi!

The HF and BF modes have the same size/precision and neither is
a subset nor superset of the other.
So, using either __extendhfbf2 or __trunchfbf2 is weird.
The expansion apparently emits __extendhfbf2, but on the libgcc side
we apparently have __trunchfbf2 implemented.

I think it is easier to switch to using what is available rather than
adding new entrypoints to libgcc, even alias, because this is backportable.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2024-05-07  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/114907
	* expr.cc (convert_mode_scalar): Use trunc_optab rather than
	sext_optab for HF->BF conversions.
	* optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.

	* gcc.dg/pr114907.c: New test.


	Jakub
  

> Am 07.05.2024 um 18:02 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> Hi!
> 
> The HF and BF modes have the same size/precision and neither is
> a subset nor superset of the other.
> So, using either __extendhfbf2 or __trunchfbf2 is weird.
> The expansion apparently emits __extendhfbf2, but on the libgcc side
> we apparently have __trunchfbf2 implemented.
> 
> I think it is easier to switch to using what is available rather than
> adding new entrypoints to libgcc, even alias, because this is backportable.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok - do we have any target patterns that need adjustments?

Thanks,
Richard 

> 2024-05-07  Jakub Jelinek  <jakub@redhat.com>
> 
>    PR middle-end/114907
>    * expr.cc (convert_mode_scalar): Use trunc_optab rather than
>    sext_optab for HF->BF conversions.
>    * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise.
> 
>    * gcc.dg/pr114907.c: New test.
> 
> --- gcc/expr.cc.jj    2024-04-09 09:29:04.000000000 +0200
> +++ gcc/expr.cc    2024-05-06 13:21:33.933798494 +0200
> @@ -355,8 +355,16 @@ convert_mode_scalar (rtx to, rtx from, i
>              && REAL_MODE_FORMAT (from_mode) == &ieee_half_format));
> 
>       if (GET_MODE_PRECISION (from_mode) == GET_MODE_PRECISION (to_mode))
> -    /* Conversion between decimal float and binary float, same size.  */
> -    tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
> +    {
> +      if (REAL_MODE_FORMAT (to_mode) == &arm_bfloat_half_format
> +          && REAL_MODE_FORMAT (from_mode) == &ieee_half_format)
> +        /* libgcc implements just __trunchfbf2, not __extendhfbf2.  */
> +        tab = trunc_optab;
> +      else
> +        /* Conversion between decimal float and binary float, same
> +           size.  */
> +        tab = DECIMAL_FLOAT_MODE_P (from_mode) ? trunc_optab : sext_optab;
> +    }
>       else if (GET_MODE_PRECISION (from_mode) < GET_MODE_PRECISION (to_mode))
>    tab = sext_optab;
>       else
> --- gcc/optabs-libfuncs.cc.jj    2024-01-03 11:51:31.739728303 +0100
> +++ gcc/optabs-libfuncs.cc    2024-05-06 15:50:21.611027802 +0200
> @@ -589,7 +589,9 @@ gen_trunc_conv_libfunc (convert_optab ta
>   if (GET_MODE_CLASS (float_tmode) != GET_MODE_CLASS (float_fmode))
>     gen_interclass_conv_libfunc (tab, opname, float_tmode, float_fmode);
> 
> -  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode))
> +  if (GET_MODE_PRECISION (float_fmode) <= GET_MODE_PRECISION (float_tmode)
> +      && (REAL_MODE_FORMAT (float_tmode) != &arm_bfloat_half_format
> +      || REAL_MODE_FORMAT (float_fmode) != &ieee_half_format))
>     return;
> 
>   if (GET_MODE_CLASS (float_tmode) == GET_MODE_CLASS (float_fmode))
> --- gcc/testsuite/gcc.dg/pr114907.c.jj    2024-05-06 15:59:08.734958523 +0200
> +++ gcc/testsuite/gcc.dg/pr114907.c    2024-05-06 16:02:38.914139829 +0200
> @@ -0,0 +1,27 @@
> +/* PR middle-end/114907 */
> +/* { dg-do run } */
> +/* { dg-options "" } */
> +/* { dg-add-options float16 } */
> +/* { dg-require-effective-target float16_runtime } */
> +/* { dg-add-options bfloat16 } */
> +/* { dg-require-effective-target bfloat16_runtime } */
> +
> +__attribute__((noipa)) _Float16
> +foo (__bf16 x)
> +{
> +  return (_Float16) x;
> +}
> +
> +__attribute__((noipa)) __bf16
> +bar (_Float16 x)
> +{
> +  return (__bf16) x;
> +}
> +
> +int
> +main ()
> +{
> +  if (foo (11.125bf16) != 11.125f16
> +      || bar (11.125f16) != 11.125bf16)
> +    __builtin_abort ();
> +}
> 
>    Jakub
>
  

On Tue, May 07, 2024 at 08:57:00PM +0200, Richard Biener wrote:
> 
> 
> > Am 07.05.2024 um 18:02 schrieb Jakub Jelinek <jakub@redhat.com>:
> > 
> > Hi!
> > 
> > The HF and BF modes have the same size/precision and neither is
> > a subset nor superset of the other.
> > So, using either __extendhfbf2 or __trunchfbf2 is weird.
> > The expansion apparently emits __extendhfbf2, but on the libgcc side
> > we apparently have __trunchfbf2 implemented.
> > 
> > I think it is easier to switch to using what is available rather than
> > adding new entrypoints to libgcc, even alias, because this is backportable.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Ok - do we have any target patterns that need adjustments?

I don't think so.
BFmode is i386/aarch64/arm/riscv backend only from what I can see,
I've done make mddump for all of them and none of the tmp-mddump.md
files show any matches for hfbf (nor bfhf).

	Jakub