From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 74A583858D1E; Tue, 25 Apr 2023 12:01:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 74A583858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 33PC0Uvm024919; Tue, 25 Apr 2023 07:00:30 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 33PC0T45024918; Tue, 25 Apr 2023 07:00:29 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 25 Apr 2023 07:00:29 -0500 From: Segher Boessenkool To: Jakub Jelinek Cc: David Edelsohn , Kewen Lin , gcc-patches@gcc.gnu.org, Xionghu Luo Subject: Re: [PATCH] powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566] Message-ID: <20230425120029.GV19790@gate.crashing.org> References: 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-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On Mon, Apr 24, 2023 at 05:54:02PM +0200, Jakub Jelinek wrote: > The problem is that the *branch_anddi3_dot define_insn_and_split > relies on the *rotldi3_mask_dot define_insn_and_split being recognized > during splitting. The rs6000_is_valid_rotate_dot_mask function checks whether > the mask is a CONST_INT which is a valid mask, but *rotl3_mask_dot in > addition to checking that it is a valid mask also has > (mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff) > test in the condition. For TARGET_64BIT that doesn't add any further > requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND > second operand is larger than INT_MAX it will not be recognized. The reason is that code that runs in 32-bit mode, (MSR[SF]=0, which is what you get with -m32 code) does the comparisons for record-form insns ("dot insns") as 32-bit compares. Often this matters. But if your insn masks with (some subset of) 0x7fffffff all three result bits (LT, GT, EQ, meaning the sign bit is set, the sign bit is not set but some other value bit is, and nobits are set, respectively) are set the same in either mode. > --- gcc/config/rs6000/rs6000.cc.jj 2023-04-04 10:33:47.433201866 +0200 > +++ gcc/config/rs6000/rs6000.cc 2023-04-24 12:31:07.237031550 +0200 > @@ -11409,7 +11409,16 @@ bool > rs6000_is_valid_rotate_dot_mask (rtx mask, machine_mode mode) > { > int nb, ne; > - return rs6000_is_valid_mask (mask, &nb, &ne, mode) && nb >= ne && ne > 0; > + if (rs6000_is_valid_mask (mask, &nb, &ne, mode) && nb >= ne && ne > 0) > + { > + if (TARGET_64BIT) > + return true; > + /* *rotldi3_mask_dot requires for -m32 -mpowerpc64 that the mask is > + <= 0x7ffffff. */ > + return (UINTVAL (mask) << (63 - nb)) <= 0x7fffffff; > + } > + else > + return false; No superfluous "else" please, just put a blank line there. Okay for trunk (with Ke Wen's remarks fixed, but you already did :-) ) Thanks! Segher