Bug 82805 - [7/8/9 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in between 6.3 and 7.2
Summary: [7/8/9 Regression] SPEC CPU2006 454.calculix ~6% performance deviation in bet...
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 7.2.0
: P3 normal
Target Milestone: 7.4
Assignee: Not yet assigned to anyone
Depends on:
Blocks: spec 84613
  Show dependency treegraph
Reported: 2017-11-02 08:42 UTC by Martin Liška
Modified: 2018-06-08 15:15 UTC (History)
3 users (show)

See Also:
Target: x86_64-*-*, i?86-*-*
Known to work:
Known to fail:
Last reconfirmed:

perf report (24.67 KB, text/plain)
2017-11-02 08:42 UTC, Martin Liška
perf report (19.90 KB, text/plain)
2017-11-02 08:43 UTC, Martin Liška
perf diff (12.80 KB, text/plain)
2017-11-02 08:58 UTC, Martin Liška

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liška 2017-11-02 08:42:14 UTC
We lost about 6% on Zen with -O2 -mtune=generic in between these 2 releases. It's quite hard to bisect a single revision.
Comment 1 Martin Liška 2017-11-02 08:42:57 UTC
Created attachment 42525 [details]
perf report
Comment 2 Martin Liška 2017-11-02 08:43:33 UTC
Created attachment 42526 [details]
perf report
Comment 3 Martin Liška 2017-11-02 08:58:07 UTC
Created attachment 42528 [details]
perf diff
Comment 4 Jan Hubicka 2017-11-02 09:39:32 UTC
Caluculix also sees smaller regression on Haswell due to the vectorization costmodel change.  I will try to take a look.
Comment 5 Richard Biener 2018-01-25 08:26:49 UTC
GCC 7.3 is being released, adjusting target milestone.
Comment 6 Martin Jambor 2018-02-08 16:27:17 UTC
January trunk revision 257023 improved a little but still loses 3.25% on gcc 6 (on Zen).
Comment 7 Martin Jambor 2018-04-20 21:35:12 UTC
According to my latest numbers. 454.alculix compiled with gcc 7 is 3% slower than gcc 6 at -O2 but trunk (r259234) is as fast as gcc 6.
Comment 8 Martin Jambor 2018-06-08 15:15:43 UTC
According to my latest GCC 8 measurements, we have caught up at some point in the final stages of GCC 8 development and in all but one option combination are noticeably faster than GCC 6.  In the only case where we aren't (-O2 and generic march/mtune), we are not really slower (only 1%).  So I'd consider this FIXED.