> Hi, Honza, > > in addition to the code size problems, there are several runtime regression > for the SPEC: (If I read the table correctly, if not, let me know) > > SPEC/SPEC2006/INT/483.xalancbmk > <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=183.290.0> 146.131 > 4.89%
This test seems to be just a noise, if you look on the mainline plots there is no noticeable regression and you can see differences +- 4% in last 10 runs. > > SPEC/SPEC2006/FP/436.cactusADM > <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=171.100.0> > 130.967 8.07% > > SPEC/SPEC2017/INT/520.omnetpp_r > <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=172.357.0> 395.582 > 4.98% Here you can see in the graph both boxes to be yellow which means that binary did not changed nor the size changed. It is just measurement error it seems. > > SPEC/SPEC2006/FP/435.gromacs > <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=177.90.0> > 182.555 11.73% I plan to check on gromacs This is LTO+PGO which will be rerun only in day or two so I will see if the same regression stays on mainline. > > SPEC/SPEC2017/INT/541.leela_r > <https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=174.397.0> > 452.333 4.17% This was already taken by daily testers and regression does not reproduce, so it seems to be noise too. Honza > > do we have plan to study and fix these run-time regression? > > thanks. > > Qing > > > On Jan 12, 2019, at 12:32 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > > > > Hello, > > this patch sets inline-unit-growth to 40. The performance changes are > > - Firefox, LTO > > > > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=f7bd026e1a931b9a284d1c85c2577a72dd592820&newProject=try&newRevision=74889968abcc688b8d161863566ed273c0401ee4&framework=1&filter=opt&showOnlyComparable=1&showOnlyImportant=1 > > After fixes to inlining priorities this makes difference without > > profile feedback only. > > > > Code size growth is about 9.15% with LTO and 3.95 with LTO and profile > > feedback. > > - Firefox noLTO > > > > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=c902b72340a3dca3114f58578c1c8f3e6a1cd89c&newProject=try&newRevision=4974da6f92c144a9c09765b56a564a640069ddb9&framework=1&showOnlyComparable=1&showOnlyImportant=1 > > With about 7% code size growth > > - SPEC > > > > https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?num_runs=10&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f > > - C++ benchmarks > > > > https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?num_runs=10&all_changes=on&min_percentage_change=0.02&revisions=46e2bd1143b5c60af814916d7673879b34ceb3f6%2Cc0d79cfe9c4ec30823480f2f9b256600e8e3899f > > > > I am not entirely happy about the code-size/performance tradeoffs but it > > is concerned only for programs built with -O3 or having too many inline > > keywords. I have looked into inlining decisions for Firefox, HHVM and > > Clang and inliner gets out of growt bounds way too early and some of > > more performance aware projects already sets the limit up. > > > > I will tune other metrics down to handle some of the code size problems. > > > > Honza > > > > Index: ChangeLog > > =================================================================== > > --- ChangeLog (revision 267882) > > +++ ChangeLog (working copy) > > @@ -1,3 +1,7 @@ > > +2019-01-05 Jan Hubicka <hubi...@ucw.cz> > > + > > + * params.def (inline-unit-growth): Set to 40. > > + > > 2019-01-12 Jakub Jelinek <ja...@redhat.com> > > > > * tree-ssa-loop-ivopts.c (find_inv_vars): Fix a comment typo. > > Index: params.def > > =================================================================== > > --- params.def (revision 267882) > > +++ params.def (working copy) > > @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS, > > DEFPARAM(PARAM_INLINE_UNIT_GROWTH, > > "inline-unit-growth", > > "How much can given compilation unit grow because of the inlining (in > > percent).", > > - 20, 0, 0) > > + 40, 0, 0) > > DEFPARAM(PARAM_IPCP_UNIT_GROWTH, > > "ipcp-unit-growth", > > "How much can given compilation unit grow because of the > > interprocedural constant propagation (in percent).", >
