From: Richard Biener <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, Linux Kbuild mailing list <email@example.com>, the arch/x86 maintainers <firstname.lastname@example.org>, stable <email@example.com>, "H.J. Lu" <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Jakub Jelinek <firstname.lastname@example.org>, Oleksandr Natalenko <email@example.com>, Arnd Bergmann <firstname.lastname@example.org>, Andrew Morton <email@example.com>, David Laight <David.Laight@aculab.com>, Masahiro Yamada <firstname.lastname@example.org> Subject: Re: [PATCH v2] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10 Date: Tue, 12 May 2020 10:44:29 +0200 (CEST) [thread overview] Message-ID: <nycvar.YFH.email@example.com> (raw) In-Reply-To: <CAHk-=wi87j=wj0ijkYZ3WoPVkZ9Fq1U2bLnQ66nk425B5kW0Cw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2651 bytes --] On Mon, 11 May 2020, Linus Torvalds wrote: > On Mon, May 11, 2020 at 2:57 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > GCC 10 appears to have changed -O2 in order to make compilation time > > faster when using -flto, seemingly at the expense of performance, in > > particular with regards to how the inliner works. Since -O3 these days > > shouldn't have the same set of bugs as 10 years ago, this commit > > defaults new kernel compiles to -O3 when using gcc >= 10. > > I'm not convinced this is sensible. Note the real thing that changed for GCC 10 at -O2 is that -O2 now includes -finline-functions which means GCC considers inlining of functions not marked with 'inline' at -O2. To counter code-size growth and tune that back to previous levels the inlining limits in effect at -O2 have been lowered. Note this has been done based on analyzing larger C++ code and obviously not because the kernel would benefit (IIRC kernel folks like 'inline' to behave as written and thus rather may dislike the change to default to -finline-functions). > -O3 historically does bad things with gcc. Including bad things for > performance. It traditionally makes code larger and often SLOWER. > > And I don't mean slower to compile (although that's an issue). I mean > actually generating slower code. > > Things like trying to unroll loops etc makes very little sense in the > kernel, where we very seldom have high loop counts for pretty much > anything. > > There's a reason -O3 isn't even offered as an option. And I think that's completely sensible. I would not recommend to use -O3 for the kernel. Somehow feeding back profile data might help - though getting such data at all and with enough coverage is probably hard. As you said in the followup I wouldn't recommend tweaking GCCs defaults for the various --param affecting inlining. The behavior with this is not consistent across releases. Richard. > Maybe things have changed, and maybe they've improved. But I'd like to > see actual numbers for something like this. > > Not inlining as aggressively is not necessarily a bad thing. It can > be, of course. But I've actually also done gcc bugreports about gcc > inlining too much, and generating _worse_ code as a result (ie > inlinging things that were behind an "if (unlikely())" test, and > causing the likely path to grow a stack fram and stack spills as a > result). > > So just "O3 inlines more" is not a valid argument. > > Linus > -- Richard Biener <firstname.lastname@example.org> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
next prev parent reply other threads:[~2020-05-12 8:44 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-07 22:45 [PATCH] " Jason A. Donenfeld 2020-05-08 8:35 ` Peter Zijlstra 2020-05-08 9:02 ` Oleksandr Natalenko 2020-05-08 11:21 ` Jason A. Donenfeld 2020-05-08 11:33 ` Oleksandr Natalenko 2020-05-08 11:49 ` Arnd Bergmann 2020-05-08 12:07 ` Jason A. Donenfeld 2020-05-08 13:04 ` Arnd Bergmann 2020-05-08 15:06 ` Joe Perches 2020-05-08 15:09 ` Arnd Bergmann 2020-05-10 12:47 ` David Laight 2020-05-10 17:45 ` Joe Perches 2020-05-10 18:58 ` David Laight 2020-05-12 1:10 ` Masahiro Yamada 2020-05-11 21:57 ` [PATCH v2] " Jason A. Donenfeld 2020-05-12 0:04 ` Linus Torvalds 2020-05-12 0:09 ` Linus Torvalds 2020-05-12 0:43 ` Jason A. Donenfeld 2020-05-12 8:44 ` Richard Biener [this message] 2020-05-13 11:27 ` [PATCH] " Artem S. Tashkinov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=nycvar.YFH.email@example.com \ --firstname.lastname@example.org \ --cc=David.Laight@aculab.com \ --cc=Jason@zx2c4.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).