Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2537376ybk; Tue, 12 May 2020 01:46:18 -0700 (PDT) X-Google-Smtp-Source: APiQypKYzhTBbQlplR7fyRpf+ILfVKlpFCVQy22EpuPgv/d2SHR+daRrO6OMugl7ph9Fw4mEO22E X-Received: by 2002:a17:906:3da:: with SMTP id c26mr17115750eja.290.1589273177986; Tue, 12 May 2020 01:46:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589273177; cv=none; d=google.com; s=arc-20160816; b=JS5kGWqzwdRepgyyK/0OfOk/YaAkicyTZz3EXBem/4ysbQEPVucefdJzJ3VLNr/+gT /KhVnf4NxBPz/OZXVAmGts90fHxbumG7RSDM3eeQaq6tljCzt4fIKvqB4jQL5ClctTS+ rDeGa2xlrMbwDKxC/+0UvV80CcCBsHkdcDEjqVAlCQ9t7J1PnOFX4a+11/wLmDEXCakP 9B2kXJTMdYRB+1OHt5zqrjGyswc6yJHlfDtro2Y3fWmGwdrlTe2ojU/+DSfjDNcLS1gK iPsU0DVkwfP5XUJX6bJKSXYmZIneMlRIISETrIh0VsUogmd47BWAiQJnUggbq+Tqmuq9 cWMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=2/GMMZd0Z0e5gn9REIHOpYk8B27I7zLOOJRxWdcor4o=; b=ibfpQj21/12mpG5puDl3HOB4PBky+U+e66QqHx/Vf5GZfIGqCBltJI4zheorC3HIFD H5KS3S+KmDCpeKt/7IUNqS1xJy5wHonFtqJU3XpG3SY+mafSXO8eHdVPSPD66JG8+T+D Nl/Wt0Fon0opIur39bSII3QkM6dvCBPy1fhjtI28VyYpm1RIGGzp1Vip/ZN9r9mc9WbE tlRAI59G9nm7pjxQzfJVb8IfbBVACWitdjHOw8P6GfN5m4NrjD3XqHxiwYiTRV3tEucH hU7i6KOEISG/r2Zgzf+ade5Jr8d+5zrUVB5j1XsYBqvKCSyQZqczoIHIHG7bWG5DOQtC yK3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id co17si7090804edb.218.2020.05.12.01.45.53; Tue, 12 May 2020 01:46:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729135AbgELIod (ORCPT + 99 others); Tue, 12 May 2020 04:44:33 -0400 Received: from mx2.suse.de ([195.135.220.15]:37344 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725776AbgELIoc (ORCPT ); Tue, 12 May 2020 04:44:32 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 08421AE57; Tue, 12 May 2020 08:44:33 +0000 (UTC) Date: Tue, 12 May 2020 10:44:29 +0200 (CEST) From: Richard Biener To: Linus Torvalds cc: "Jason A. Donenfeld" , Linux Kernel Mailing List , Linux Kbuild mailing list , the arch/x86 maintainers , stable , "H.J. Lu" , Peter Zijlstra , Jakub Jelinek , Oleksandr Natalenko , Arnd Bergmann , Andrew Morton , David Laight , Masahiro Yamada Subject: Re: [PATCH v2] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10 In-Reply-To: Message-ID: References: <20200508090202.7s3kcqpvpxx32syu@butterfly.localdomain> <20200511215720.303181-1-Jason@zx2c4.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609908220-634017890-1589273070=:4397" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609908220-634017890-1589273070=:4397 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 11 May 2020, Linus Torvalds wrote: > On Mon, May 11, 2020 at 2:57 PM Jason A. Donenfeld 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 SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg) ---1609908220-634017890-1589273070=:4397--