https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782
--- Comment #43 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to hubicka from comment #42) > I also see a 6.69% regression on x64 with -Ofast -march=native -flto > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=475.377.0 I can reproduce this with -Ofast -flto -march=znver3 (but not running on a Zen 3). It looks like it's due to g:d3ff7420e94 instead though (sorry Andre!). With a 3-iteration run, I see a 6.2% regression after that revision compared with before it. It would be great if someone more familiar than me with x86 could confirm the bisection though. > and perhaps 3-5% on sphinx > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=476.280.0 > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=227.280.0 I'll look at these next. > For non-spec benchmarks spec there is a regression on nbench > https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=26.645.1 > There are also large changes in tsvc > https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report > it may be noise since kernels are tiny, but for example x293 reproduces > both on kabylake and zen by about 80-90% regression that may be easy to > track (the kernel is included in the testsuite). Same regression is not > seen on zen3, so may be an ISA specific or so. To summarise what we discussed on irc (for the record): it looks like the s293 regression is in the noise, like you say. I can't convince GCC to generate different code before and after the IRA patches for that. I haven't looked at the other tsvc tests yet.
