From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D4BAF3858D35; Sun, 5 Mar 2023 08:06:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D4BAF3858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678003598; bh=ieOeQ+eR66ljB+y5AfpphuU+44yo5nnfKy3jcsfv/L0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=f0bz7FHD9m0rcd8AYrwinA3HwZPdRyJ4PzIlh7JhSJxmjbboUOQ0pDswUbTKzWhjO WzJIKqnzSPPuG/6HQ/Ba+wKGJb9ON/zUCoQ9DP+PTpRkkpdvQ/3MzuGve5S5FxfOAk JTifxkNEDNNImO2EF24AHwr2sDyVYHOYixyfyBiY= From: "roger at nextmovesoftware dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode Date: Sun, 05 Mar 2023 08:06:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization, patch X-Bugzilla-Severity: normal X-Bugzilla-Who: roger at nextmovesoftware dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106594 --- Comment #14 from Roger Sayle --- This really is a regression, that points to a previously latent/unnoticed b= ug in combine. In GCC 12, combine would take the input RTL and based on target costs trans= form it into the better of implementation A or B. Now in GCC 13, the tree-optimizers are able to perform this same optimization earlier and so combine is now given optimal implementation A, where a latent bug always transforms this to B without ever checking target costs. The consensus is that performing (more) optimizations at the tree-level is a good thing, so reverting changes to the tree optimizers (that now produce better code) is a workaround to a glitch where combine is transforming RTL = into more expensive forms. There's already a code path in combine that checks/compares costs, it just isn't being reached any more. p.s. this has nothing to do with sign_extract/zero_extract, for which hardw= are support would be hypothetical, this patch only affects sign_extend/zero_ext= end, such as aarch64's sxtw or x86_64's movsx or powerpc's extsw. If a target h= as this functionality, it's unlikely that a sequence of shifts or bit-wise operations would be better.=