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...
Status: RESOLVED FIXED
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
URL:
Keywords:
Depends on:
Blocks: spec 84613
  Show dependency tree / graph
 
Reported: 2017-11-02 08:42 UTC by Martin Liška
Modified: 2018-06-08 15:15 UTC (History)
3 users (show)

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

Attachments
perf report (24.67 KB, text/plain)
2017-11-02 08:42 UTC, Martin Liška 		Details
perf report (19.90 KB, text/plain)
2017-11-02 08:43 UTC, Martin Liška 		Details
perf diff (12.80 KB, text/plain)
2017-11-02 08:58 UTC, Martin Liška 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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.