On Tue, Sep 20, 2016 at 1:31 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Fri, Sep 16, 2016 at 2:00 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >>> > > I also like a new param better as it avoids a new magic constant and >>> > > makes playing with >>> > > it easier (your patch removes the ability to do statistics like you did >>> > > via the >>> > > early-inlining-insns parameter by forcing it to two). >>> > >>> > Hmm, you are right that you do not know if this particular function will >>> > get >>> > profile (forgot about that). Still, please use two params - it is more >>> > consistent with what we have now and we may make it profile specific in >>> > future.. >>> > >>> > Honza >>> > > >>> > > Thanks, >>> > > Richard. >>> >>> A new patch for trunk is attached. >>> >>> Regards, >>> Yuan, Pengfei >>> >>> >>> 2016-09-16 Yuan Pengfei <y...@pku.edu.cn> >>> >>> * doc/invoke.texi (--param early-inlining-insns-feedback): New. >>> * ipa-inline.c (want_early_inline_function_p): Use >>> PARAM_EARLY_INLINING_INSNS_FEEDBACK when FDO is enabled. >>> * params.def (PARAM_EARLY_INLINING_INSNS_FEEDBACK): Define. >>> (PARAM_EARLY_INLINING_INSNS): Change help string accordingly. > > Btw, It occurs to me that then win in code-size might be purely due to the > smaller base value for the TU size we use to compute the maximum unit > growth with ... any idea how to improve it on this side? Say, computing > the TU size before early optimization (uh, probably not ...) > > That said, the inliner always completely fills its budged, that is, increase > the unit by max-unit-growth?
What I'm trying to say is that rather than limiting early inlining we should maybe decrease inline-unit-growth when FDO is in effect? Because we can better control where the inlining goes. If there is over 8% reduction in size benchmarking (unpatched) compiler on Firefox with FDO and --param inline-unit-growth=12 might show if the results are the same. Richard. > Richard. > >> OK, >> thanks >> >> Honza
