On Wed, 05 Feb 2025 09:57:56 PST (-0800), ja...@redhat.com wrote:
Hi!

The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))

The reason for the ICE is that op1 in this case is CONST_POLY_INT
which unlike the really expected VOIDmode CONST_INTs has its own
mode and still satisfies CONSTANT_P.
GET_MODE (rhs) (SImode) is different from outer_mode (DImode), so
the function later does
        *inner_step = simplify_gen_binary (code, outer_mode,
                                           *inner_step, op1);
but that obviously ICEs because while *inner_step is either VOIDmode
or DImode, op1 has SImode.

The following patch fixes it by extending op1 using code so that
simplify_gen_binary can handle it.  Another option would be
to change the !CONSTANT_P (op1) 3 lines above this to
!CONST_INT_P (op1), I think it isn't very likely that we get something
useful from other constants there.

Bootstrapped/regtested on x86_64-linux and i686-linux (which doesn't
tell much because such code isn't encountered there, just that the
gcc.dg test at least works), but I have no way to test this on riscv
easily.  Could somebody test it there?

The precommit CI should pick it up, as it's got "RISC-V" in the subject line. I don't see it in the list yet, though.

Or do you want the
!CONST_INT_P (op1) instead?

Jeff would know way better than I do here, but I think this is just trying to match addiw-type patterns and thus CONST_INT would be OK because we only have 12-bit constants here.

Probably best to wait for Jeff, though...


2025-02-05  Jakub Jelinek  <ja...@redhat.com>

        PR rtl-optimization/117506
        * loop-iv.cc (get_biv_step_1): For {ZERO,SIGN}_EXTEND
        of PLUS apply {ZERO,SIGN}_EXTEND to op1.

        * gcc.dg/pr117506.c: New test.
        * gcc.target/riscv/pr117506.c: New test.

--- gcc/loop-iv.cc.jj   2025-01-29 21:12:28.741974212 +0100
+++ gcc/loop-iv.cc      2025-02-05 13:36:15.357827426 +0100
@@ -714,6 +714,7 @@ get_biv_step_1 (df_ref def, scalar_int_m
          if (!simple_reg_p (op0) || !CONSTANT_P (op1))
            return false;

+         op1 = simplify_gen_unary (code, outer_mode, op1, GET_MODE (rhs));
          prev_code = code;
          code = PLUS;
        }
--- gcc/testsuite/gcc.dg/pr117506.c.jj  2025-02-05 13:34:08.522619613 +0100
+++ gcc/testsuite/gcc.dg/pr117506.c     2025-02-05 13:25:01.990342131 +0100
@@ -0,0 +1,18 @@
+/* PR rtl-optimization/117506 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -funroll-loops" } */
+
+char a;
+int b;
+unsigned c;
+short d;
+
+void
+foo ()
+{
+  for (short f = 0; f < c; f += 3)
+    {
+      a ^= d;
+      b = b < 0 ? b : 0;
+    }
+}
--- gcc/testsuite/gcc.target/riscv/pr117506.c.jj        2025-02-05 
13:34:24.594392519 +0100
+++ gcc/testsuite/gcc.target/riscv/pr117506.c   2025-02-05 13:35:19.221620634 
+0100
@@ -0,0 +1,5 @@
+/* PR rtl-optimization/117506 */
+/* { dg-do compile } */
+/* { dg-options "-march=rv64im_zve64f -mabi=lp64 -O3 -funroll-loops" } */
+
+#include "../../gcc.dg/pr117506.c"

        Jakub

Reply via email to