From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C78063858CDA; Fri, 12 Aug 2022 17:01:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C78063858CDA From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode Date: Fri, 12 Aug 2022 17:01:36 +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: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: roger at nextmovesoftware 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: 13.0 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: Fri, 12 Aug 2022 17:01:36 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106594 --- Comment #5 from Roger Sayle --- Hi Tamar, I think this is where I need to apologize. Combine is now canonicalizing t= hese equivalent RTL expressions to the zero_extend form, on the assumption that = zero extension has no data dependency and is cheaper or at worst the same speed = on many targets. Unfortunately, for aarch64 there are patterns (splitters or peephole2s) for optimizing the sign_extend version that don't exist for the zero_extend version [even though the instruction set is symmetric and should handle both sxtw/uxtw]. Technically, these were just missed-optimizations before, but I'm guessing my changes (to both trees and RTL) lead to change= s in the form that the backend encounters, and leads to a code quality regressio= n. This should be easy to fix, I just need to get up to speed on the instructi= ons that aarch64 supports, and which zero extended forms are currently missing. I'm sure if GCC instead canonicalized to the sign_extend form, that other targets would show similar asymmetries (it's only when things change that anyone notices the difference). I'll see if I can come up with a fix over = the weekend.=