From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 13AE03857C51; Wed, 6 Mar 2024 20:05:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13AE03857C51 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1709755552; bh=7CI9jdo0h7erPrb7y1b8ZZATW2Zpo0bgw06ANDGrdhw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fptKomik1OnoBFs/TsUCU2JaPS4Ma75cfBnOjaNrft9jkY7hR6ayptJOWHnVjmjRo LiRn1u4jD53iztyYPifLwVnzudS9uhRSRz6jN1RKKJh+EfBDsnymKOUj+hddd8+I/n rCG0jjoAi0AgdEfE8oMYdGk501LWCbkrQiwjTL/E= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193 Date: Wed, 06 Mar 2024 20:05:50 +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: 14.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114151 --- Comment #13 from Andrew Macleod --- Created attachment 57638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D57638&action=3Dedit patch Ok, there were 2 issues with simply invoking range_of_stmt, which this new patch resolves. IF we aren't looking to fix this in GCC 14 right now anywa= y, this is the way to go. 1) The cache has always tried to provide a global range by pre-folding a st= mt for an estimate using global values. This is a bad idea for PHIs when SCEV= is invoked AND SCEV is calling ranger. This changes it to not pre-evaluate PHI= s, which also saves time when functions have a lot of edges. Its mostly pointl= ess for PHIs anyway since we're about to do a real evaluation. 2) The cache's entry range propagator was not re-entrant. We didn't previo= usly need this, but with SCEV (and possible other place) invoking range_of_expr without context and having range_of_stmt being called, we can occasionally = get layered calls for cache filling (of different ssa-names)=20 With those 2 changes, we can now safely invoke range_of_stmt from a context= less range_of_expr call. We would have tripped over this earlier if SCEV or one of those other places using range_of_expr without context had instead invoked range_of_stmt. That would have been perfectly reasonable, and would have resulting in these same issues. We never tripped over it because range_of_stmt is not used much outside of ranger. That is the primary reason I wanted to track this down.= =20 There were alternative paths to the same end result that would have trigger= ed these issues. Give this patch a try. it also bootstraps with no regressions. I will queu= e it up for stage 1 instead assuming all is good.=