> >> > 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. > > > > AFAIK, param inline-unit-growth only affects pass_ipa_inline. However, the > > code > > size reduction achieved with my patch is from pass_early_inline. > > Any inlining you don't do at early inlining time will a) decrease the > size inline-unit-growth > is computed on b) just delays inlining to IPA inlining (with the now > more constrained size budget).
Delaying inlining from early inlining to IPA inlining can save size because profile feedback is effective at IPA inlining and inlining of cold functions can be avoided. Otherwise, inlining done at early inlining can not be canceled later. Yuan, Pengfei > Richard. > > > Yuan, Pengfei
