From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DDF623858C33; Fri, 7 Jul 2023 06:12:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDF623858C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1688710353; bh=PO606ZRh3uOQqHn6YhyIXZnHMxsYNoRJKkFrDIlNU8o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TxyAbRZyqFiYhHdHgry01BMtT6mEArrP87E3AU6o9ek3pKskU8rergHdZ0/sPPiPF 3h8EylnbfR9CjUWhqKc5lhgr0G2DdMukYdkvC9XcZ1z+ylnZFDGGwXhSZ4FgpGnADP EivCS4dup8GB6sFT8TA0jatYvlUCydxaq3K7Fl+g= From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109874] [SH] GCC 13's -Os code is 50% bigger than GCC 4's Date: Fri, 07 Jul 2023 06:12:33 +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: 13.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D109874 Oleg Endo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olegendo at gcc dot gnu.org --- Comment #3 from Oleg Endo --- (In reply to Richard Biener from comment #2) > It looks like the target cannot do arbitrary constant shifts so it benefi= ts > from shifting incrementally. Even if that is exposed early enough for CSE > the optimal sequences for shifting by 10, 11, 12 and 13 could prevent CSE > here. That's right. SH1, SH2 doesn't have a barrel shifter and needs stitched constant shifts. In some cases we resort to a rt lib call to avoid code bl= oat. There are a couple of opportunities when sharing intermediate results of incremental / stitched shifts. A while ago I had the idea of writing an RTL pass that would try to figure that out... In this case the shifts are expanded to RTL with the constant shift amounts already propagated and the incremental shifts removed, so it's a bit harder= to undo this at the RTL level, but not impossible. On SH3, SH4 dynamic shifts are available, but it requires another register + constant load. Incremental / stitched shifts would be always better on SH = for this test case.=