From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 82C10386103C; Sat,  1 Aug 2020 19:30:10 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82C10386103C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1596310210;
 bh=5Ul0zasWV1kYg/yRBmNPqUsUK5skP8hJ4/lG9D1tU0w=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=swcjbqhJoomRXaRD7D3kvYI04UKIAd20EZEYKt4zLynDVJJK+tRs+VGdBOFIWJ0Ho
 4OmXXUANobOTUJmaY5P+jXNQlwdECnS4byMgQQjjVRbI2mDUs8QVu0blDn5pIwXreg
 fWL648jWquihrGDtGsrXSi2j2Dh+2qEdhPlvrgLw=
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2
 -march=x86-64 vs. GCC 9.3/8.4
Date: Sat, 01 Aug 2020 19:30:10 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 10.2.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-96337-4-Si1Y2CBBoy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-96337-4@http.gcc.gnu.org/bugzilla/>
References: <bug-96337-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Aug 2020 19:30:10 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96337

--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
> I think, this inliner change needs to be reverted. People expect -O2 to p=
roduce
> decently optimized binaries, and starting with gcc 10.x it doesn't delive=
r. -O3
> traditionally enabled optimizations that may or may not improve performan=
ce
> (and historically, sometimes even break code), so most projects don't use=
 it.
I wrote a short description of inliner changes to the phoronix
discussion
https://www.phoronix.com/forums/forum/software/programming-compilers/119678=
9-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an=
-unexpected-surprise/page5
comment 44.

Inliner changes was not targetting to make compile time faster and
compiled code slower. It was intended to reflect more closely modern C++
codebases and get faster binaries (at -O2 and -O2 -flto) without
regressing in code sizes.  In fact more inlining happens and thus we
needed to optimize inliner code carefully to avoid regressions with LTO.

It was benchmarked on wide range of bechmarks including some where
phoronix measured a degradation before GCC10 release.

The benchmarks presented does not reproduce and seems odd. 50% on very
simple benchmarks is bit too much for a change in one optimization.  It
seems more like thermal throttling. Michael promised to re-run the tests
and he is still spekaing about htat in the last reply from 31st.

Testcases are greatly welcome.

Honza=