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? > > 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? Andreas > > Richard. > >> jeff >> >> >>
