[Bug target/101345] wrong code at -O1 with vector modulo

["jeevitha at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Jeevitha <jeevitha at gcc dot gnu.org> ---

> Jeevitha, can you please do a git bisect from the two commits above to
> identify the commit that fixes this for posterity sake?  Thanks.

The commit that resolved the incorrect code was
ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for mult
with subreg. This addressed the issue.

The reason behind this change is as follows:

The input for the swap pass is,

insn 23 set r144, vec_concat(r152,r160)
insn 26 set r162, r237*(r144+0)
insn 27 set r163, (r144+8)*r236
insn 29 set r166, r236*(r144+0)
insn 30 set r167, subreg(r236*(r144+0),8)


Output from swap pass is,

insn 23 set r144, vec_concat(r160,r152)
insn 26 set r162, r237*(r144+8)
insn 27 set r163, (r144+0)*r236
insn 29 set r166, r236*(r144+8)
insn 30 set r167, subreg(r236*(r144+8),0)

In the provided sample code, multiplication operations are performed. Here, the
SUBREG_BYTE changes in pseudo 144 are correct. However, the change from 8 to 0
in the SUBREG_BYTE of MULT(r236,r144) is incorrect. This alteration leads to
treating it as a low-part multiply ie, similar to insn 29, whereas it should
actually a high-part multiply. Therefore, Bill stopped the swap for mult with
subreg case, which resolves this issue.

To provide clear reference, here is the RTL for insn 30 in failure case:

(insn 30 29 31 2 (set (reg:DI 167)
        (subreg:DI (mult:TI (zero_extend:TI (reg:DI 236))
-              (zero_extend:TI (subreg:DI (reg:V2DI 144) 0))) 8))
"test1.c":13:5 166 {umuldi3_highpart_le} //input from swap pass
+               (zero_extend:TI (subreg:DI (reg:V2DI 144) 8))) 0))
"test1.c":13:5 166 
{umuldi3_highpart_le} //output from swap pass