[PATCH] bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

[PATCH] bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

[Jakub Jelinek]

Hi!

We don't really support _Complex _BitInt(N), the only place we use
bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function
results and COMPLEX_EXPR in the usual case should be either not present
yet because the ifns weren't folded and will be lowered, or optimized
into something simpler, because normally the complex bitint should be
used just for extracting the 2 subparts from it.
Still, with disabled optimizations it can occassionally happen that it
appears in the IL and that is why there is support for lowering those,
but it doesn't handle optimizing those too much, so if it uses SSA_NAME,
it relies on them having a backing VAR_DECL during the lowering.
This is normally achieves through the
                      && ((is_gimple_assign (use_stmt)
                           && (gimple_assign_rhs_code (use_stmt)
                               != COMPLEX_EXPR))
                          || gimple_code (use_stmt) == GIMPLE_COND)
hunk in gimple_lower_bitint, but as the following testcase shows, there
is one thing I've missed, the load optimization isn't guarded by the
above stuff.  So, either we'd need to add support for loads to
lower_complexexpr_stmt, or because they should be really rare, this
patch just disables the load optimization if at least one load use is
a COMPLEX_EXPR (like we do already for PHIs, calls, asm).

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

2024-06-19  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/115544
	* gimple-lower-bitint.cc (gimple_lower_bitint): Disable optimizing
	loads used by COMPLEX_EXPR operands.

	* gcc.dg/bitint-107.c: New test.

--- gcc/gimple-lower-bitint.cc.jj	2024-06-07 12:17:09.811966904 +0200
+++ gcc/gimple-lower-bitint.cc	2024-06-19 15:27:22.378759911 +0200
@@ -6630,7 +6630,10 @@ gimple_lower_bitint (void)
 		    continue;
 		  if (gimple_code (use_stmt) == GIMPLE_PHI
 		      || is_gimple_call (use_stmt)
-		      || gimple_code (use_stmt) == GIMPLE_ASM)
+		      || gimple_code (use_stmt) == GIMPLE_ASM
+		      || (is_gimple_assign (use_stmt)
+			  && (gimple_assign_rhs_code (use_stmt)
+			      == COMPLEX_EXPR)))
 		    {
 		      optimizable_load = false;
 		      break;
--- gcc/testsuite/gcc.dg/bitint-107.c.jj	2024-06-19 15:36:32.817747449 +0200
+++ gcc/testsuite/gcc.dg/bitint-107.c	2024-06-19 14:03:31.383805280 +0200
@@ -0,0 +1,16 @@
+/* PR tree-optimization/115544 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+typedef _BitInt(129) B;
+#else
+typedef _BitInt(63) B;
+#endif
+B a, b;
+
+int
+foo (void)
+{
+  return __builtin_mul_overflow (a, 1, &b);
+}

	Jakub

Re: [PATCH] bitint: Fix up lowering of COMPLEX_EXPR [PR115544]

[Richard Biener]

> Am 19.06.2024 um 20:44 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> Hi!
> 
> We don't really support _Complex _BitInt(N), the only place we use
> bitint complex types is for the .{ADD,SUB,MUL}_OVERFLOW internal function
> results and COMPLEX_EXPR in the usual case should be either not present
> yet because the ifns weren't folded and will be lowered, or optimized
> into something simpler, because normally the complex bitint should be
> used just for extracting the 2 subparts from it.
> Still, with disabled optimizations it can occassionally happen that it
> appears in the IL and that is why there is support for lowering those,
> but it doesn't handle optimizing those too much, so if it uses SSA_NAME,
> it relies on them having a backing VAR_DECL during the lowering.
> This is normally achieves through the
>                      && ((is_gimple_assign (use_stmt)
>                           && (gimple_assign_rhs_code (use_stmt)
>                               != COMPLEX_EXPR))
>                          || gimple_code (use_stmt) == GIMPLE_COND)
> hunk in gimple_lower_bitint, but as the following testcase shows, there
> is one thing I've missed, the load optimization isn't guarded by the
> above stuff.  So, either we'd need to add support for loads to
> lower_complexexpr_stmt, or because they should be really rare, this
> patch just disables the load optimization if at least one load use is
> a COMPLEX_EXPR (like we do already for PHIs, calls, asm).

Sounds reasonable.

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

Ok

Richard 

> 2024-06-19  Jakub Jelinek  <jakub@redhat.com>
> 
>    PR tree-optimization/115544
>    * gimple-lower-bitint.cc (gimple_lower_bitint): Disable optimizing
>    loads used by COMPLEX_EXPR operands.
> 
>    * gcc.dg/bitint-107.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj    2024-06-07 12:17:09.811966904 +0200
> +++ gcc/gimple-lower-bitint.cc    2024-06-19 15:27:22.378759911 +0200
> @@ -6630,7 +6630,10 @@ gimple_lower_bitint (void)
>            continue;
>          if (gimple_code (use_stmt) == GIMPLE_PHI
>              || is_gimple_call (use_stmt)
> -              || gimple_code (use_stmt) == GIMPLE_ASM)
> +              || gimple_code (use_stmt) == GIMPLE_ASM
> +              || (is_gimple_assign (use_stmt)
> +              && (gimple_assign_rhs_code (use_stmt)
> +                  == COMPLEX_EXPR)))
>            {
>              optimizable_load = false;
>              break;
> --- gcc/testsuite/gcc.dg/bitint-107.c.jj    2024-06-19 15:36:32.817747449 +0200
> +++ gcc/testsuite/gcc.dg/bitint-107.c    2024-06-19 14:03:31.383805280 +0200
> @@ -0,0 +1,16 @@
> +/* PR tree-optimization/115544 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 129
> +typedef _BitInt(129) B;
> +#else
> +typedef _BitInt(63) B;
> +#endif
> +B a, b;
> +
> +int
> +foo (void)
> +{
> +  return __builtin_mul_overflow (a, 1, &b);
> +}
> 
>    Jakub
>