On Tue, Sep 20, 2016 at 1:57 PM, Yuan, Pengfei <y...@pku.edu.cn> wrote: >> > 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). Richard. > Yuan, Pengfei
