[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 30 Jan 2018, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665
> 
> --- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> Yes, I have started experiments with adjusting inliner limits: hopefully we can
> tune up speedup limit because it is now applied more agresively (due to lack of
> capping) and perhaps tune down size limits because we do better early opts and
> time/size estimations.
> 
> Last week we did some work with Martin Liska verifying that profile propagation
> now works as expected and things seems to be in order now in ways we can test
> (i.e. no zero profiles on places where they should not be and IPA/BB profiles
> are in sync). Before those bugs was chased away inliner retuning made little
> sense.
> 
> From experiments this week I know that tramp3d still need early inlining of 14,
> but other limits seems to have gained quite some border on spec2000/2006.  I
> would like to use czerny for searching the space this week and hope that tuning
> some parameters down is still OK at this stage?

I think we can tolerate one change in terms of addressing code size
regressions but it's really late now already.  So if you end up
with profitable changes please post the patch and ask for an OK.