[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 Josef Melcr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Josef Melcr --- Closing as fixed. Thanks :)
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #14 from rguenther at suse dot de --- On Thu, 4 Jun 2026, jmelcr at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 > > --- Comment #13 from Josef Melcr --- > I'll create the reports for the rest. Do we leave this one open, given that > it's almost there? I think we can close it then.
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #13 from Josef Melcr --- I'll create the reports for the rest. Do we leave this one open, given that it's almost there?
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #12 from Richard Biener --- The exchange2 regressions seem to be mostly (some 2-3% seem left) resolved, the other issues should get separate bugreports, it makes it unwieldly to track this all in one bug, even if caused by the same change.
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #11 from Richard Biener --- https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=694.407.0 shows the expected progression on Zen3 with ix86-vect-compare-costs=1, as does https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1249.407.0 (not that's not PGO). Waiting for the original reported testers to get a new result...
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a22b31304e0a1ad21751f882c02c32c167c78793 commit r17-223-ga22b31304e0a1ad21751f882c02c32c167c78793 Author: Richard Biener Date: Fri Apr 24 14:35:49 2026 +0200 flip --param ix86-vect-compare-costs default The following flips the default of ix86-vect-compare-costs as discussed during stage3/4. It adds the testcase from PR120398 and ensures the existing one works without specifying the --param. Testcases have been adjusted with simple dump scan adjustments. gcc.target/i386/vect-epilogues-10.c shows that we compute the masked epilog to be more expensive than the not masked one. That's probably correct as we're facing an in-order reduction. I have added -fno-vect-cost-model given this is a testcase for a missing feature. PR tree-optimization/120398 PR tree-optimization/123603 * config/i386/i386.opt (ix86-vect-compare-costs): Default to 1. * gcc.dg/vect/costmodel/x86_64/costmodel-pr120398.c: New testcase. * gcc.dg/vect/costmodel/x86_64/costmodel-pr123603.c: Adjust. * gcc.target/i386/vect-alignment-peeling-1.c: Likewise. * gcc.target/i386/vect-alignment-peeling-2.c: Likewise. * gcc.target/i386/vect-epilogues-10.c: Add -fno-vect-cost-model.
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #9 from Josef Melcr --- Zen5 2017 exchange2_r -O2 -g -flto=128 with PGO as well https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1244.407.0
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603
--- Comment #8 from Richard Biener ---
(In reply to Josef Melcr from comment #7)
> 2006 calculix with -Ofast -march=x86-64-v3 -g -flto=128 on Zen4 is also
> affected.
>
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1119.170.0
We're vectorizing
e_c3d.f:680:34: optimized: loop vectorized using 16 byte vectors and unroll
factor 2
that's
do i1=1,3
iii1=ii1+i1-1
do j1=1,3
jjj1=jj1+j1-1
do k1=1,3
===> this loop do l1=1,3
s(iii1,jjj1)=s(iii1,jjj1)
& +anisox(i1,k1,j1,l1)*w(k1,l1)*weight
do m1=1,3
s(iii1,jjj1)=s(iii1,jjj1)
& +anisox(i1,k1,m1,l1)*w(k1,l1)
& *vo(j1,m1)*weight
& +anisox(m1,k1,j1,l1)*w(k1,l1)
& *vo(i1,m1)*weight
do n1=1,3
s(iii1,jjj1)=s(iii1,jjj1)
& +anisox(m1,k1,n1,l1)
& *w(k1,l1)*vo(i1,m1)*vo(j1,n1)
& *weight
enddo
enddo
enddo
enddo
enddo
enddo
In GCC 15 we've not vectorized the loop. -mno-fma makes no difference
in runtime (but we do have FMA chains in both cases). This is because of
t.f:15:34: note: ==> examining statement: _26 = (*w_93(D))[_25];
t.f:15:34: missed: single-element interleaving not supported for not adjacent
vector loads, using elementwise access
vs.
t.f:15:34: note: ==> examining statement: _26 = (*w_93(D))[_25];
t.f:15:34: missed: single-element interleaving not supported for not adjacent
vector loads
t.f:17:72: missed: not vectorized: relevant stmt not supported: _26 =
(*w_93(D))[_25];
which means we can now vectorize sth we couldn't before. Iff the same
bisection holds that just made it profitable. It's definitely a different
"bug".
t.f:15:34: note: Cost model analysis:
Vector inside of loop cost: 1008
Vector prologue cost: 68
Vector epilogue cost: 752
Scalar iteration cost: 736
Scalar outside cost: 0
Vector outside cost: 820
prologue iterations: 0
epilogue iterations: 1
Calculated minimum iters for profitability: 2
I also see we're not hoisting invariant vector CTORs emitted by the
vectorizer, because CONSTRUCTOR_NELTS is easily lower than LIM_EXPENSIVE
(20). Fixing that doesn't help though, RTL invariant motion does this
already and we spill some of the required invariants. With zen5 tuning
we don't vectorize, the costs there prevent this.
We have building blocks like
_489 = {_182, _182};
...
vect__188.234_743 = MEM [(real(kind=8) *)_860 + -72B
+ ivtmp.526_1082 * 1];
vect__188.247_769 = MEM [(real(kind=8) *)_860 + 136B
+ ivtmp.526_1082 * 1];
vect__188.261_796 = VEC_PERM_EXPR ;
vect__201.203_117 = MEM [(real(kind=8) *)_860];
vect__201.216_66 = MEM [(real(kind=8) *)_860 +
208B];
vect__201.230_27 = VEC_PERM_EXPR ;
_869 = .FMA (vect__201.230_27, _489, vect__188.261_796);
where the permutes are basically from pices construction, so we have three
from-pieces vectors fed into .FMA which feeds a reduction chain. Vector
costing does not have FMA, so it costs two scalar add / mul against
one add / mul plus the permutes on the vector side.
_78 + _250 1 times vector_stmt costs 12 in body
_121 * _220 1 times vector_stmt costs 20 in body
(*anisox_92(D))[_176] 1 times vec_perm costs 4 in body
(*anisox_92(D))[_249] 2 times unaligned_load (misalign -1) costs 24 in body
182 * _201 1 times scalar_stmt costs 20 in epilogue
_55 + _188 1 times scalar_stmt costs 12 in epilogue
(*anisox_92(D))[_176] 1 times scalar_load costs 12 in epilogue
so for this building block the vector variant wins by 20 + 12 - 4 which
is enough. vector construction of the invariants also costs 4, so that's
at least sensibly the same as the permute. What likely makes the difference
is tieing previously independent chains into two-element vectors, giving
less OOO freedom to the CPU. Something we do not model at all.
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 --- Comment #7 from Josef Melcr --- 2006 calculix with -Ofast -march=x86-64-v3 -g -flto=128 on Zen4 is also affected. https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1119.170.0
[Bug target/123603] [16/17 Regression] 13% slowdown of exchange2_r on Zen4 since r16-6767-g948d33f490a6b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123603 Richard Biener changed: What|Removed |Added Keywords||deferred Summary|[16 Regression] 13% |[16/17 Regression] 13% |slowdown of exchange2_r on |slowdown of exchange2_r on |Zen4 since |Zen4 since |r16-6767-g948d33f490a6b0|r16-6767-g948d33f490a6b0 Target Milestone|16.0|17.0 Priority|P3 |P2
