> I think, this inliner change needs to be reverted. People expect -O2 to > produce > decently optimized binaries, and starting with gcc 10.x it doesn't deliver. > -O3 > traditionally enabled optimizations that may or may not improve performance > (and historically, sometimes even break code), so most projects don't use it. I wrote a short description of inliner changes to the phoronix discussion https://www.phoronix.com/forums/forum/software/programming-compilers/1196789-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an-unexpected-surprise/page5 comment 44.
Inliner changes was not targetting to make compile time faster and compiled code slower. It was intended to reflect more closely modern C++ codebases and get faster binaries (at -O2 and -O2 -flto) without regressing in code sizes. In fact more inlining happens and thus we needed to optimize inliner code carefully to avoid regressions with LTO. It was benchmarked on wide range of bechmarks including some where phoronix measured a degradation before GCC10 release. The benchmarks presented does not reproduce and seems odd. 50% on very simple benchmarks is bit too much for a change in one optimization. It seems more like thermal throttling. Michael promised to re-run the tests and he is still spekaing about htat in the last reply from 31st. Testcases are greatly welcome. Honza
