From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E9BA1398543D; Tue, 3 Nov 2020 14:16:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9BA1398543D From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97623] [9/10/11 Regression] Extremely slow O2 compile (>>O(n^2)) Date: Tue, 03 Nov 2020 14:16:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 9.3.1 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 14:16:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97623 --- Comment #8 from Richard Biener --- (In reply to Wilson Snyder from comment #7) > Thanks for the quick service. I can't easily try GCC trunk, but: >=20 > -O2 > compile 98.61s > runtime 25.76s >=20 > -O2 -fno-code-hoisting > compile 40.13s > runtime 26.40s (+2.5%) Hmm, OK. Can you provide the output of -O2 -fno-code-hoisting -ftime-repor= t? I have a patch limiting hoist insertions to 3 and that makes the reduced testcase drop from 13s to 2.5s and drop PRE into reasonable territory: tree PRE : 0.44 ( 18%) 0.00 ( 0%) 0.45 ( = 18%) 1177k ( 5%) and with -fno-code-hoisting tree PRE : 0.37 ( 15%) 0.00 ( 0%) 0.38 ( = 15%) 477k ( 2%) where it takes only two insert iterations (the last iteration is always a no-op, so that's perfect). Before limiting but after the already committed patch it was tree PRE : 10.41 ( 81%) 0.01 ( 33%) 10.48 ( = 81%) 11M ( 33%) The function is quite big and ANTIC_IN compute is costly and more importantly AVAIL_OUT is quadratic in size (ugh). > -Os > compile 4.25s > runtime 23.42s (-10%) >=20 > That -Os runs faster is expected as this program is generally > instruction-fetch limited. I'd have expected -fno-code-hoisting to help > more, compile time wise. Me, too. > Am I correct in understanding that the slowdown is roughly correlated to = the > number of "if" or "?:" statements? Yeah, that's the case.=