https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119971
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <l...@gcc.gnu.org>: https://gcc.gnu.org/g:05d75c5bfcf923bc0258b79a08c5861590c5a2b9 commit r16-394-g05d75c5bfcf923bc0258b79a08c5861590c5a2b9 Author: Jeff Law <j...@ventanamicro.com> Date: Mon May 5 17:14:29 2025 -0600 [RISC-V][PR target/119971] Avoid losing shift count masking As is outlined in the PR, we have a few define_insn_and_split patterns which optimize away explicit masking of shift/bit positions when the masking matches what the hardware's behavior. A small number of those define_insn_and_split patterns generate a single instruction. It's fairly elegant in that we were essentially just rewriting the RTL to match an existing pattern. In one case we'd do the rewriting and later turn a 32bit shift into a bset. That's not safe because the masking of a 32bit shift uses 0x1f while masking on bset uses 0x3f on rv64. The net was incorrect code as seen in the BZ entry. The fix is pretty simple. There's no real reason we need to use a define_insn_and_split. It was just convenient. Instead we can use a simple define_insn. That avoids a change in the masking behavior for the shift count/bit position and the masking stays in the RTL. I quickly scanned the entire port and didn't see any additional define_insn_and_splits that obviously generated a single instruction outside the shift/rotate space, though in the vector space that's nontrivial to ascertain. This was been run through my tester for the cross configurations, but not the native bootstrap/regression test (yet). PR target/119971 gcc/ * config/riscv/bitmanip.md (rotation with masked count): Rewrite as define_insn patterns. Fix formatting. * config/riscv/riscv.md (shift with masked count): Similarly. gcc/testsuite * gcc.target/riscv/pr119971.c: New test. * gcc.target/riscv/zbb-rol-ror-03.c: Adjust test slightly.
