From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 244CD3858D3C; Fri, 26 May 2023 12:03:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 244CD3858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685102616; bh=lt1AtZf5fhrT+S2W7TkWmU/gtZvKBf3K7A50+kDBVoY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Pr2uoGAXEvX2ksy4ThWpv9S/9LhHX6pfnJP0V1XPejB94ponJ0IMmM7Ff7ZMupRN7 7+J9AunZb2v7+7WDivDMwI8apC2L8pmwA8mzBi9KMUrg0CeKUNOu23S9wG3LW2Ypxe 5FwFQNtHXf2UsuTHtuM+VTHcqw/Tki4fnY8LR+Is= From: "klepikov.alex+bugs at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction Date: Fri, 26 May 2023 12:03:34 +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: 4.6.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: klepikov.alex+bugs at gmail dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: olegendo at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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=3D49263 --- Comment #41 from Alexander Klepikov --- > > It looks like with optimization enabled it converts bitwise AND to right > > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be > > optimized to 'tst'. And SH2E has libcall instead of dynamic shift and l= ibcll > > cannot be converted. It seems that very first optimization spoils thing= s. > >=20 > > But when we have numerous 'shar' instructions, optimization joins the g= ame > > again and converts them to 'tst'. >=20 > Yes, something like this is what I remember happening there. I'll try to > look into the issue with your test cases and see if it's possible to add > some patterns to catch those. Thank you! I have an idea. If it's impossible to defer initial optimization, maybe it's possible to emit some intermediate insn and catch it and optimize later? > BTW, have you tried it on a more recent GCC? There have also been some > optimizations in the middle-end (a bit more backend independent) for this > kind of thing. I tried 13.1 about week or two ago with the same result. > Have you tried to use whole program optimization via -flto and > -ffunction-sections? It should be able to strip out all unnecessary libr= ary > functions. Thank you for advice, I'll take a try.=