[Bug rtl-optimization/123883] Inefficient bit manipulation code on RISC-V port

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123883

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
I don't think the before/after RTL semantics are correct on the new pattern. 
Consider the second operand of the IOR:

(sign_extend:DI (ashift:SI (const_int 1) (shift count)))

When the shift count is 31, that must generate 0xffffffff80000000.  Thus all
those bits must be on in the final result, irrespective of the other operand of
the IOR.

If we look at the output you generate

(ior:DI (ashift:DI (const_int 1) (match_dup 1))
        (match_dup 2))


If our count is 31, that will flip on 0x80000000, but the upper 32 bits will
come exclusively from (match_dup 2) when they should all be on according to the
input RTL.