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.
