* [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]
@ 2024-05-07 16:01 Jakub Jelinek
2024-05-07 18:57 ` Richard Biener
0 siblings, 1 reply; 3+ messages in thread
From: Jakub Jelinek @ 2024-05-07 16:01 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
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.
--- 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]
2024-05-07 16:01 [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907] Jakub Jelinek
@ 2024-05-07 18:57 ` Richard Biener
2024-05-07 19:28 ` Jakub Jelinek
0 siblings, 1 reply; 3+ messages in thread
From: Richard Biener @ 2024-05-07 18:57 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
> 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
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907]
2024-05-07 18:57 ` Richard Biener
@ 2024-05-07 19:28 ` Jakub Jelinek
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Jelinek @ 2024-05-07 19:28 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-05-07 19:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-07 16:01 [PATCH] expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907] Jakub Jelinek
2024-05-07 18:57 ` Richard Biener
2024-05-07 19:28 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).