From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6F1A23865C2D; Thu, 25 Feb 2021 09:50:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F1A23865C2D From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/99083] Big run-time regressions of 519.lbm_r with LTO Date: Thu, 25 Feb 2021 09:50:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: missed-optimization, patch, ra X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ubizjak at gmail dot com X-Bugzilla-Target-Milestone: 11.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status keywords assigned_to resolution 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: Thu, 25 Feb 2021 09:50:18 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99083 Uro=C5=A1 Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Keywords| |patch Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail do= t com Resolution|FIXED |--- --- Comment #13 from Uro=C5=A1 Bizjak --- (In reply to Martin Jambor from comment #12) > For the record, I have benchmarked the patches from comment #4 and comment > #10 on top of commit 6b1633378b7 (for which I already have unpatched > benchmark results) and the regression of 519.lbm_r compiled with -O2 LTO > dropped from 62% to 8%.=20=20 >=20 > The -Ofast -march=3Dnative -flto vs. non-LTO regression also dropped from= 8% > to about 5% (GCC 10 also has non-LTO 2.5% faster than LTO, but at least b= oth > times improved vs. GCC 10). >=20 > The only notable regression brought about the patch was 538.imagick_r when > compiled at -Ofast -march=3Dnative without LTO, which was 6% slower with = the > patch. >=20 > All of the measurements were done on a Zen2 machine. >=20 > Thank you for reverting the patch, now we need to look for LNT to pick up > the changes. The complete patch that presumably corrects HONOR_REG_ALLOC_ORDER usage is = at [1], but IIUC the above measurements, there is still a regression of 8% vs unpat= ched compiler. With the complete patch [1], ira_better_spill_reload_regno_p cha= nge should be a NO-OP, but the new default also disables the internal calculati= ons in assign_hard_reg, please see [2] for reasoning. Based on the above benchmarks, it looks that disabling the internal calculations in assign_hard_reg is harmful even for HONOR_REG_ALLOC_ORDER targets, at least patched x86 compiler shows this effect. Maybe Vlad could comment this part. Let's reopen this PR to keep the discussions in one place. [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565640.html [2] https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565699.html=