https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115640
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 25 Jun 2024, tschwinge at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115640 > > Thomas Schwinge <tschwinge at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Summary|GCN: FAIL: |[15 Regression] GCN: FAIL: > |gfortran.dg/vect/pr115528.f |gfortran.dg/vect/pr115528.f > | -O execution test | -O execution test > See Also| |https://gcc.gnu.org/bugzill > | |a/show_bug.cgi?id=114107 > > --- Comment #5 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- > Turns out, this is a regression after all: before commit > r15-1238-g1fe55a1794863b5ad9eeca5062782834716016b2 "tree-optimization/114107 - > avoid peeling for gaps in more cases", this test case > 'gfortran.dg/vect/pr115528.f' (which, of course, wasn't in-tree back then) > does > PASS its execution test for GCN target (tested '-march=gfx908'). Yes, the testcase outer loop wasn't vectorized before due to the "gap" access in the inner loop. With this rev. we can now vectorize the inner loop without touching the gap. Note I'm no longer sure the loop mask use is what's wrong. Instead it looks like the IV for 'aa' is off (just like I remember what happens when there is a grouped access in the inner loop): # vectp_aa.21_73 = PHI <vectp_aa.21_72(8), vectp_aa.21_75(3)> ... vect__14.23_71 = .MASK_LOAD (vectp_aa.21_73, 64B, loop_mask_77); vectp_aa.21_70 = vectp_aa.21_73 + 18446744073709551360; // -256 ... vectp_aa.21_72 = vectp_aa.21_70 + 32; for the inner loop - but the inner loop should advance by 32. So I think the issue is a latent one, but maybe one that couldn't be triggered. _Possibly_ it could be triggered with V2mode vectors. For an inner loop with a grouped access this case is still disqualified but IIRC it has the same issue.
