On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel <kreb...@linux.ibm.com> wrote: > > On 30.04.20 08:25, Richard Biener via Gcc-patches wrote: > > On Wed, Apr 29, 2020 at 5:56 PM Jeff Law <l...@redhat.com> wrote: > >> > >> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote: > >>> > >>> Btw, does s390 have different inlining parameters somehow? > >> I think so. We saw a ton of backend warnings that were specific to the > >> s390 > >> builds in Fedora that appeared to be triggered by different inlining > >> decisions. > >> > >> It happened enough that one of the ideas we're going to explore is seeing > >> if we > >> can tune the x86_64 port to use the same heuristics. That way we can try > >> to find > >> more of these issues in our tester without having to dramatically increase > >> s390x > >> resourcing. This hasn't started, but I expect we'll be looking at it in > >> the fall > >> (it's unclear if we can just use flags or will need hackery to the x86 > >> port, but > >> we're happy to share whatever we find with the wider community). > > > > Hmm, OK. Guess if it becomes an issue for openSUSE I'll simply revert those > > s390 backend changes. > > Too bad. I would prefer to fix the root cause of the warnings instead. Isn't > it a good thing that > thanks to the more aggressive inlining actual bugs in the code get revealed? > Or do you see other > issues with that?
I'm obviously more concerned about latent GCC issues only popping up on s390. Basically the s390 limits throw much of the QA done on x86_64 targets away when comparing to s390. For example we do burn-in testing of a new GCC release (10.1 here) in openSUSE Factory by using it as system compiler. Then with GCC 10.2 we ship it as compiler for their own use to SLES users and ISVs. But obviously all the burn-in testing on openSUSE Factory is very x86_64 centric these days. > > > > As a general advice to backend developers I _strongly_ discourage to adjust > > --param defaults that affect GIMPLE. > > We did tons of measurements to find these values recently and got a nice > speedup after increasing > them. We also had a look at the size increase of binaries. It was significant > but we decided that > the performance benefit is worth it. On IBM Z the function call overhead is > bigger than on other > archs so inlining in general helps us. > > I'm not sure I understand your recommendation to leave these values as is. I > assumed that such > parameters are supposed to be used to deal with the characteristics of a > platform. Are there better > ways to achieve the same effect? Get more inlining than other archs? No, I don't think so. But if the call overhead is bigger then you should adjust the cost of calls instead? Also the default limits are a delicate compromise between speed and size - of course if you disregard size you get more speed. You also only adjusted two out of very many params which are not really as independent as one would think... (and you forgot to re-tune after last years big changes/parameter space splits). As said you should at least think of adjusting the adjustments to be relative to the default value rather than absolute. Richard. > Andreas > > > > > Richard. > > > >> jeff > >> > >> > >> >
