When compiled with -O2 -march=native and run on an AMD Zen2 CPU, 531.deepsjeng_r runs about 7% slower. This can be bisected to a single commit: commit a9a4edf0e71bbac9f1b5dcecdcf9250111d16889 Author: Jan Hubicka <hubicka@ucw.cz> Date: Sat Nov 30 22:25:24 2019 +0100 Update max_bb_count in execute_fixup_cfg * tree-cfg.c (execute_fixup_cfg): Update also max_bb_count when scaling happen. From-SVN: r278879 Surprisingly, I cannot see a similar problem on an Intel Cascade Lake server CPU, but I have confirmed the above on two different Rome systems (one running SLES, one openSUSE Tumbleweed).
I can confirm on LNT znver2 machine, but the bisection points to a different commit: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=324.387.0&plot.1=311.387.0&plot.2=348.387.0&plot.3=280.387.0&plot.4=297.387.0& while LNT znver1 machine is not affected and the speed is similar to GCC 9: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=145.387.0&plot.1=49.387.0&plot.2=79.387.0&plot.3=259.387.0&plot.4=29.387.0&
The regression dropped to 1.9% according to my own measurements which also match LNT (linked above). It is peculiar to an unusual option combination, specific to Zen2 (I cannot see it on Zen3 or CascadeLake) and so I think it is unreasonable to expect that anybody will actually want to work on it. And the PR really is mostly fixed, so let me close it as such.