[RISC-V][PR target/119971] Avoid losing shift count masking

[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.

(cherry picked from commit 05d75c5bfcf923bc0258b79a08c5861590c5a2b9)