https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- good (base) vs. bad (peak) on Zen2 with -Ofast -march=native shows Samples: 654K of event 'cycles', Event count (approx.): 743149709374 Overhead Samples Command Shared Object Symbol 16.71% 109793 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] hsmoc_ 14.37% 94016 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] hsmoc_ 8.82% 57979 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] lorentz_ 8.48% 55451 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] lorentz_ 4.84% 31575 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] momx3_ 4.68% 30456 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] momx3_ 4.08% 26675 zeusmp_peak.amd zeusmp_peak.amd64-m64-mine [.] tranx3_ 3.56% 23145 zeusmp_base.amd zeusmp_base.amd64-m64-mine [.] tranx3_ for hsmoc_ it looks like a difference in transformations done: -hsmoc.f:826:19: optimized: loop vectorized using 32 byte vectors (there are a lot more missed vectorizations). subroutine hsmoc ( emf1, emf2, emf3 ) integer is, ie, js, je, ks, ke common /gridcomi/ & is, ie, js, je, ks, ke integer in, jn, kn, ijkn integer i , j , k parameter(in = 128+5 & , jn = 128+5 & , kn = 128+5) parameter(ijkn = 128+5) real*8 emf1 ( in, jn, kn), emf2 ( in, jn, kn) real*8 vint (ijkn), bint (ijkn) do 199 j=js,je+1 do 59 i=is,ie do 858 k=ks,ke+1 vint(k)= k bint(k)= k 858 continue do 58 k=ks,ke+1 emf1(i,j,k) = vint(k) emf2(i,j,k) = bint(k) 58 continue 59 continue 199 continue return end doesn't reproduce it though. The actual difference for the whole testcase is of course failed data-ref analysis: Creating dr for (*emf2_1966(D))[_402] -analyze_innermost: success. - base_address: emf2_1966(D) - offset from base address: (ssizetype) ((((sizetype) _1928 * 17689 + (sizetype) j_2705 * 133) + (sizetype) i_2672) * 8) - constant offset from base address: -142584 - step: 141512 - base alignment: 8 +analyze_innermost: hsmoc.f:828:72: missed: failed: evolution of offset is not affine. + base_address: + offset from base address: + constant offset from base address: + step: + base alignment: 0 and then hsmoc.f:826:19: note: === vect_analyze_data_ref_accesses === -hsmoc.f:826:19: missed: not consecutive access (*emf1_1964(D))[_402] = _403; -hsmoc.f:826:19: note: using strided accesses -hsmoc.f:826:19: missed: not consecutive access (*emf2_1966(D))[_402] = _404; -hsmoc.f:826:19: note: using strided accesses and we use gather and fail because of costs. I suspect that relying on global ranges (that could save us here) is quite fragile when there's a lot of other code around and thus opportunity for random transforms "trashing" them. Using the patch from PR114151 and enabling ranger during vectorization oddly enough doesn't help (even when wiping the SCEV cache). The odd thing is with the testcase above we get Access function 0: (integer(kind=8)) {(((unsigned long) _30 * 17689 + (unsigned long) _10) + (unsigned long) _66) + 18446744073709533793, +, 17689}_4; where you can see some of the unsigned promotion being done, but we still succeed. As I'm lacking a smaller testcase right now it's difficult to understand why we fail in one case but not the other.