https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473
--- Comment #11 from Hongtao.liu <crazylht at gmail dot com> --- (In reply to Martin Jambor from comment #10) > (In reply to Hongtao.liu from comment #6) > > Does it means cycles? > > Basically yes, AFAIK. Basically I ran both versions under perf record > and then processed the output (so that is not so wide) of perf report > -n --stdio --percent-limit=2 (where -n is the thing that gives you > "samples"). > > > Vtune data show __module_mp_wsm5_MOD_nislfv_rain_plm has less instructions > > retired and clocksticks after my commit. And the regression comes from > > libc-2.31.so which shoud be the same. > > I tend to think that any glibc from 2.29 is good enough to reproduce this. > For what it's worth, the system I tried this on has glib 2.33 > I tried, the regression also exists for glibc 2.33 and 2.28. And also on ICX. > My examination was very preliminary, because wrf takes ages to build, > I hoped I would point people to the important bit. I am not sure I > succeeded though. > > (In reply to Hongtao.liu from comment #8) > > > > I'm going to revert the patch. > > This is your call. I actually dot not think that compiling wrf_r for > pre-AVX2 targets is a very important use case, the regression was just > so consistent that I thought it was worth investigating (and of course > it would be great if it could be avoided). Yes, Still investigating why, it may hit some microarchitecture bound which can't be explained w/o help from hardward team. > > So it depends whether the patch has speed benefits in more common > circumstances or not.
