[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.0, 14.0 CC||jeevitha at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Last reconfirmed||2024-4-18 --- Comment #1 from Peter Bergner --- I can confirm the checkout used at the time (b019b28ebd65462a092c96d95e9e356c8bb39b78) does produce "subfic rX,rX,4". That said, with commit b85e79dce149df68b92ef63ca2a40ff1dfa61396 (about the time gcc13 branches), it is fixed to "subfic rX,rX,2", so I'm marking this as RESOLVED/FIXED. It remains fixed since that commit too. Jeevitha, can you please do a git bisect from the two commits above to identify the commit that fixes this for posterity sake? Thanks.
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > Jeevitha, can you please do a git bisect from the two commits above to > identify the commit that fixes this for posterity sake? Thanks. I'll note I used -O1 -mcpu=power8 for my compiles.
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345
--- Comment #3 from Jeevitha ---
> 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
[Bug target/101345] wrong code at -O1 with vector modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101345 Peter Bergner changed: What|Removed |Added Depends on||101129 --- Comment #4 from Peter Bergner --- (In reply to Jeevitha from comment #3) > The commit that resolved the incorrect code was > ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0, where Bill disabled the swap for > mult with subreg. This addressed the issue. Ok, so that was the fix for PR101129. Thanks for tracking that down Jeevitha! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 [Bug 101129] [11/12 Regression] wrong code at -O1 since r11-5839
