https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126056
Filip Kastl <pheeck at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[17 Regression] 25% |[17 Regression] 25%
|slowdown of 470.lbm on AMD |slowdown of 470.lbm on AMD
|Zen5 and 7% 538.imagick_r |Zen5 since
|on Zen4 since |r17-1845-g23b6a9a41a5c05
|r17-1845-g23b6a9a41a5c05 |
--- Comment #2 from Filip Kastl <pheeck at gcc dot gnu.org> ---
(In reply to Filip Kastl from comment #1)
> Another slowdown at the same commit:
>
> 7% on SPEC CPU 2017
Oh, nevermind. Wanted to report this
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1108.507.0
but it has meanwhile disappeared. So only the lbm slowdown remains
But looking at the graph for lbm, I think that one will also disappear. Might
be some sort of code alignment thing or the register allocator getting
(un)lucky. lbm is a small benchmark and you can see that the runtime oscilates
betwen two values. So I guess that your patch simply influenced some minor
compiler decision which the big loop nest in the benchmark magnified into 25%
slowdown.
So maybe let's keep this open in case someone wants to dig into this to speedup
the benchmark. Otherwise I wouldn't worry about it. The benchmark runtime
will probably eventually drop to the previous values anyway.
