[PR target/121778] Improving rotation detection

[PR target/121778] Improving rotation detection

In this PR we're getting code like this out of the gimple optimizers:

>   _1 = a_4(D) << 63;
>   _2 = a_4(D) >> 1;
>   _3 = _2 ^ 1;
>   _5 = _1 | _3;

Note the XOR in that sequence.  It spoils our ability to recognize the
rotation.  As a result we get code like this for rv64gcb:

>         srli    a5,a0,1
>         xori    a5,a5,1
>         slli    a0,a0,63
>         or      a0,a5,a0

We can reassociate the operations when the XOR only flips bits resulting from
the right or left shift, but not both.  So after reassociation in gimple we
get:

>   _1 = a_2(D) r>> 1;
>   _3 = _1 ^ 1;

Which results in:

>         rori    a0,a0,1
>         xori    a0,a0,1

We don't bother with the transformation when the XOR is flipping a bit known to
be zero (ie, a high bit of the result of the right shift or a low bit on the
result of the left shift).  For those cases we already figure out that the XOR
is just an IOR and the right things already "just happen".

This triggered some code generation changes on the SH (not surprising because
this BZ was derived from an older SH BZ).  It doesn't seem to significantly
improve the SH code, though it does turn a cmp/pz + rotate through carry with a
rotate + xor with immediate.    That may be a latency win on the SH, I really
don't know.

Shreya did the bulk of the work here.  My contribution was the sister pattern
which has the XOR on the other operand and testcase development.

Bootstrapped and regression tested on x86 & riscv.  Also tested across the
various embedded targets without any regressions.

	PR target/121778
gcc/
	* match.pd: Add pattern to recognize rotate with one or more
	bits flipped via xor.
	* config/sh/sh.md (*rotcl); New variant which handles the output
	we get after the match.pd change above.

gcc/testsuite/
	* gcc.target/riscv/pr121778.c: New test.

Co-Authored-By: Jeff Law <jeffrey.law@oss.qualcomm.com>