On 11/14/19 5:38 AM, Jan Hubicka wrote: > Hi, > this patch bumps inline-insns-single-O2 from 30 to 70. I originally reduced > it from 120 to 50 when forking the -O2 and -O3 parameters which has > quite significant code size benefits. > > This parameter controls how large functions user declared inline are inlined > (sadly we really can't inline all). > > However while this transform is mostly SPEC netutral it has turned out to > cause > performance regression for tramp3d, botan and some of Firefox benchmarks with > LTO. > > I re-measured everything with 30, 50, 70 and 90 values as seen here: > > https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=ead4ea7bb1b1b531c2d8ba72fc5c1f1b14ddc454%2Ced81e91c55436bb949fab8556c138488b598af9e%2C44f7fe6bc09fc2365c4ec9ec7aea2863593d87fc%2C6f4da220ebfa0c3a3db02109dcb371da27516a3b%2C7aa+fd3ce8a81b45e040dae74e38a6849c65883ba > > Ignore the benzen results since it run only part of the tests. > Also ignore everything which is not with -Ofast. It is noise. > > The off noise observations are: > > - 6% regression for Povray at 50, 70, 90 (6%). This is bit of independent > problem which I will treat independently > - 4% improvement for gcc for 90 > - 4% improvement for xalancbmk for 90 > - 2% improvement for parest for 70, 90 > - 12% improvement for Deesjeng for 50, 70, 90 > > Most sensitive code size wise is xalanc, about 15% growth for 50+ > > To see code size one needs to click "Display all ELF stats", set minimum > threshold to 0.001 and click generate. Once page is fully loaded add > total.*text to Filter. > > The overall outcome is growth > > 50 70 90 > spec 2006 0.51% 0.89% 1.12% > spec 2006 LTO 0.34% 0.60% 0.79% > spec 2017 2.06% 2.48% 2.57% > > https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=ead4ea7bb1b1b531c2d8ba72fc5c1f1b14ddc454%2Ced81e91c55436bb949fab8556c138488b598af9e%2C44f7fe6bc09fc2365c4ec9ec7aea2863593d87fc%2C6f4da220ebfa0c3a3db02109dcb371da27516a3b%2C7aa+fd3ce8a81b45e040dae74e38a6849c65883ba > > Short story > - many of botan tests like bumping limits up, about 1/3 of them all the way > to > 90 (there was no improvments for 120). > - nbench like increase to 50 and more > - polyhedron ttf2 likes 50 and more > - tramp3d likes 90 > > I also run Firefox LTO benchmarks: > > 30 > https://treeherder.mozilla.org/#/jobs?repo=try&revision=90a908c19de521482cad5ff864f8f67fec6dbc75 > 50 > https://treeherder.mozilla.org/#/jobs?repo=try&revision=7efe0bfd2f5acb55b1bcf0ba4a162e59b1a3be99 > 70 > https://treeherder.mozilla.org/#/jobs?repo=try&revision=6a7cf9728e4a952eff5190abeb72a4a95571d95d > 90 > https://treeherder.mozilla.org/#/jobs?repo=try&revision=5157552ce80419ed5bd0594668a53a13a04786d2 > > In all cases I used --param inline-unit-growth=12000 since this limit > otherwise blocks > inliner before it gets into function sizes in question. Code size is as > folows: > > libxul.so size: > > 30 103798151 > 50 108490103 (+4%) > 70 114372911 (+10%) > 90 116104639 (+11%) > > Compares: > 30 to 50: > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=5157552ce80419ed5bd0594668a53a13a04786d2&newProject=try&newRevision=7efe0bfd2f5acb55b1bcf0ba4a162e59b1a3be99&framework=1 > (this shows almost nothing) > 30 to 70: > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=90a908c19de521482cad5ff864f8f67fec6dbc75&newProject=try&newRevision=6a7cf9728e4a952eff5190abeb72a4a95571d95d&framework=1 > (here is 14% improvement for dormaeo benchamrk and 5% in overall > responsiveness, there is regression in tsvgx/tresize which can be > tracked down to quite low lever hand optimized code in SKIA graphics > rendering library which does not define ALWAY_INLINE to always_inline > for GCC (only for clang)) > 30 to 90: > https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=90a908c19de521482cad5ff864f8f67fec6dbc75&newProject=try&newRevision=5157552ce80419ed5bd0594668a53a13a04786d2&framework=1 > (generally similar to previous one) > > So most improvments shows up with 70 and 50 seems to not be enough to get > performance for Firefox. We still lose on tramp3d and some of botan, but I > think this is generally -O3/-Ofast type of code so I hope it is acceptable. > > The SPEC code sizes are not very realistic, since a lot of codebases are > Fortran or old C which do not use inlined keyword at all. On the other hand > Firefox sizes are not realistic either (in other direction) since I disabled > the inline-unit-growth parameter. > > I hope that once Martin get Tumbleweed builds with GCC 10 branch working, we > can verify how much this makes difference in larger scale. > > Bootstrapped/regtested x86_64-linux, will commit it shortly. > > * params.opt (inline-insns-single-O2): Bump from 30 to 70. BTW, you note Firefox builds above. I'm getting some link failures for libxul in seamonkey (which I think shares a lot of code with Firefox). Stuff like:
> BUILDSTDERR: /usr/bin/ld: ../../gfx/thebes/Unified_cpp_gfx_thebes1.o: in > function `gfxTextRun::SetSpaceGlyph(gfxFont*, mozilla::gfx::DrawTarget*, > unsigned int, unsigned short)': > BUILDSTDERR: > /builddir/build/BUILD/seamonkey-2.49.5/seamonkey-2.49.5/mozilla/gfx/thebes/gfxTextRun.cpp:1377: > undefined reference to `gfxShapedWord* gfxFont::GetShapedWord<unsigned > char>(mozilla::gfx::DrawTarget*, unsigned char const*, unsigned int, unsigned > int, mozilla::unicode::Script, bool, int, unsigned int, gfxTextPerfMetrics*)' > BUILDSTDERR: /usr/bin/ld: libxul.so: hidden symbol > `_ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordPN7mozilla3gfx10DrawTargetEPKT_jjNS3_7unicode6ScriptEbijP18gfxTextPerfMetrics' > isn't defined > BUILDSTDERR: /usr/bin/ld: final link failed: bad value > BUILDSTDERR: collect2: error: ld returned 1 exit status > BUILDSTDERR: make[4]: *** > [/builddir/build/BUILD/seamonkey-2.49.5/seamonkey-2.49.5/mozilla/config/rules.mk:809: > libxul.so] Error 1 > make[4]: Leaving directory > '/builddir/build/BUILD/seamonkey-2.49.5/seamonkey-2.49.5/obj-x86_64-pc-linux-gnu/toolkit/library' I haven't dug into these yet, but I'd hazard a guess they're related to the IPA bits that have been changing the last couple months. Any chance you could take a looksie? (seamonkey 2.49.5 FWIW) I also have seen a clean build of firefox yet in my tester, but I haven't looked at it at all yet. jeff
