]> git.ipfire.org Git - thirdparty/gcc.git/commit
loop-iv, riscv: Fix get_biv_step_1 for RISC-V [PR117506]
authorJakub Jelinek <jakub@redhat.com>
Thu, 6 Feb 2025 14:39:18 +0000 (15:39 +0100)
committerJakub Jelinek <jakub@gcc.gnu.org>
Thu, 6 Feb 2025 14:39:18 +0000 (15:39 +0100)
commitbb9cee8928f7f4dfb94e7a8f232eda736b711450
tree45adfc02beff89ade41dbb906bb718068ff2aac3
parent5282e13a938404d7d4edc0ccfe6cbe9b4f980d7e
loop-iv, riscv: Fix get_biv_step_1 for RISC-V [PR117506]

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.

2025-02-06  Jakub Jelinek  <jakub@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
gcc/testsuite/gcc.dg/pr117506.c [new file with mode: 0644]
gcc/testsuite/gcc.target/riscv/pr117506.c [new file with mode: 0644]