From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTP id BE1F7381DCF6 for ; Wed, 18 Mar 2020 23:51:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BE1F7381DCF6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=segher@kernel.crashing.org Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jEiTN-0005ae-GB for gcc-patches@gcc.gnu.org; Wed, 18 Mar 2020 19:51:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2 Received: from gate.crashing.org ([63.228.1.57]:53254) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jEiTN-0005Zw-9T for gcc-patches@gcc.gnu.org; Wed, 18 Mar 2020 19:51:41 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 02INpcbF022154; Wed, 18 Mar 2020 18:51:38 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 02INpbsU022153; Wed, 18 Mar 2020 18:51:37 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 18 Mar 2020 18:51:37 -0500 From: Segher Boessenkool To: "Yangfei (Felix)" Cc: "gcc-patches@gcc.gnu.org" , "Zhanghaijian (A)" Subject: Re: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero Message-ID: <20200318235137.GP22482@gate.crashing.org> References: <20200312235008.GL22482@gate.crashing.org> <20200313160729.GT22482@gate.crashing.org> <20200316175801.GA22482@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 63.228.1.57 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 23:51:43 -0000 Hi! On Tue, Mar 17, 2020 at 02:05:19AM +0000, Yangfei (Felix) wrote: > > Trying 7 -> 8: > > 7: r99:SI=r103:SI>>0x8 > > REG_DEAD r103:SI > > 8: r100:SI=r99:SI&0x6 > > REG_DEAD r99:SI > > Failed to match this instruction: > > (set (reg:SI 100) > > (and:SI (lshiftrt:SI (reg:SI 103) > > (const_int 8 [0x8])) > > (const_int 6 [0x6]))) > > > > That should match already, perhaps with a splitter. aarch64 does not have > > very generic rotate-and-mask (or -insert) instructions, so the > > aarch64 backend needs to help combine with the less trivial cases. > > > > If you have a splitter for *this* one, all else will probably work > > "automatically": you split it to two ubfm, and the second of those can then > > merge into the compare instruction, and everything works out. > > Do you mean splitting the above pattern into a combination of ubfx and ubfiz? (Both are aliases of ubfm). Sure. The problem with aarch's bitfield instruction is that either the source or the dest has to be right-aligned, which isn't natural for the compiler. > I still don't see how the benefit can be achieved. > The following is the expected assembly for the test case: > tst x0, 1536 > cset w0, ne > ret > This may not happen when the remaining ubfx is there. Also what instruction be matched when ubfiz is merged into the compare? > Anything I missed? The second insn could combine with the compare, and then that can combine back further. Another approach: Trying 7 -> 9: 7: r99:SI=r103:SI>>0x8 REG_DEAD r103:SI 9: cc:CC_NZ=cmp(r99:SI&0x6,0) REG_DEAD r99:SI Failed to match this instruction: (set (reg:CC_NZ 66 cc) (compare:CC_NZ (and:SI (lshiftrt:SI (reg:SI 103) (const_int 8 [0x8])) (const_int 6 [0x6])) (const_int 0 [0]))) This can be recognised as just that "tst" insn, no? But combine (or simplify-rtx) should get rid of the shift here, just the "and" is simpler after all (it just needs to change the constant for that). > Also it's interesting to see how this may affect on those archs. Yes. Which is why "canonicalisation" rules that are really just "this works better on targets A and B" do not usually work well. Rules that are predictable and that actually simplify the code might still need all targets to update (and target maintainers will grumble, myself included), but at least that is a way forwards (and not backwards or sideways). Segher