https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93404
Bug ID: 93404
Summary: [10 regression] -O2 and -O2 -flto SPEC2006 and 2017
code size regression
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I am looking into this for a while, but lets create a tracking bug to record
some info on the problem.
-O2 code size seems to keep getting bigger which is not a good thing.
From
https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch?sorting=&all_elf_detail_stats=on
We get following comparing text segment sizes to gcc 6
GCC 7 GCC 8 GCC 9 GCC 10
SPECint2006 -O2: ~ ~ ~ ~
SPECfp2006 -O2: ~ ~ ~ 6.94%
SPECint2006 -O2 -flto: ~ ~ ~ 11.72%
SPECfp2006 -O2 -flto: ~ ~ ~ 8.84%
SPECint2017 -O2: ~ ~ 2.58% 10.33%
SPECfp2018 -O2: ~ ~ 3.56% 14.47%
SPECint2017 -O2: ~ ~ ~ 9.77%
SPECfp2018 -O2: ~ 2.42% ~ 18.97%
Of course, -O3 also gets progressively bigger. LNT uses ~ for values which it
considers noise (that is bit funny for sizes that are noise free), but clearly
GCC 10 regressed more than previous releases.
In GCC 10 timeframe a large portion of -flto -O2 growth is enabling
auto-inlining, but it is not the only issue here, because w/o LTO the change
actually improved code size.
In December I compared current -O2 inlining to GCC 9 style inlining and also to
auto inlining with -O3 params:
SPEC text segment effect
Benchmark -O2 -O2 with -O3 style inlining
SPECint2006 -O2 generic 0.32% 12.08%
SPECfp2006 -O2 generic -0.16% 2.99%
SPECint2006 -O2 generic LTO 11.79% 29.33%
SPECfp2006 -O2 generic LTO 1.72% 6.24%
SPECint2017 -O2 generic -1.49% 11.17%
SPECfp2017 -O2 generic -0.33% 3.76%
SPECint2017 -O2 generic LTO 10.99% 20.63%
SPECfp2017 -O2 generic LTO 4.07% 11.09%
First column compares GCC 9 -O2 inliner setting to one after patch and second
to -O3 settings. Things has improved a bit since December, so i will try to
get fresh numbers.
