From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 2744E3857016 for ; Wed, 19 Aug 2020 10:32:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2744E3857016 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D186E1063; Wed, 19 Aug 2020 03:32:16 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0AC6F3F6CF; Wed, 19 Aug 2020 03:32:15 -0700 (PDT) From: Richard Sandiford To: Przemyslaw Wirkus Mail-Followup-To: Przemyslaw Wirkus , "gcc-patches\@gcc.gnu.org" , Richard Earnshaw , Marcus Shawcroft , Kyrylo Tkachov , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" , Richard Earnshaw , Marcus Shawcroft , Kyrylo Tkachov Subject: Re: [PATCH PR96357][GCC][AArch64]: could not split insn UNSPEC_COND_FSUB with AArch64 SVE References: Date: Wed, 19 Aug 2020 11:32:14 +0100 In-Reply-To: (Przemyslaw Wirkus's message of "Wed, 19 Aug 2020 05:49:21 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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, 19 Aug 2020 10:32:18 -0000 Przemyslaw Wirkus writes: > Hi, > > Problem is related to that operand 4 (In original pattern > *cond_sub_any_const) is no longer the same as operand 1, and so > the pattern doesn't match the split condition. > > Pattern *cond_sub_any_const is being split by this patch into two > separate patterns: > * Pattern *cond_sub_relaxed_const now matches const_int > SVE_RELAXED_GP operand. > * Pattern *cond_sub_strict_const now matches const_int > SVE_STRICT_GP operand. > * Remove aarch64_sve_pred_dominates_p condition from both patterns. Thanks for doing this. > @@ -5271,6 +5270,43 @@ (define_insn_and_rewrite "*cond_sub_any_const" > [(set_attr "movprfx" "yes")] > ) > > +;; Predicated floating-point subtraction from a constant, merging with an > +;; independent value. The previous pattern had the same comment. Maybe add: The subtraction predicate and the merge predicate are allowed to be different. to the relaxed one and: The subtraction predicate and the merge predicate must be the same. to this one. > +(define_insn_and_rewrite "*cond_sub_strict_const" > + [(set (match_operand:SVE_FULL_F 0 "register_operand" "=w, w, ?w") > + (unspec:SVE_FULL_F > + [(match_operand: 1 "register_operand" "Upl, Upl, Upl") > + (unspec:SVE_FULL_F > + [(match_dup 1) > + (const_int SVE_STRICT_GP) > + (match_operand:SVE_FULL_F 2 "aarch64_sve_float_arith_immediate") > + (match_operand:SVE_FULL_F 3 "register_operand" "w, w, w")] > + UNSPEC_COND_FSUB) > + (match_operand:SVE_FULL_F 4 "aarch64_simd_reg_or_zero" "Dz, 0, w")] > + UNSPEC_SEL))] > + "TARGET_SVE > + && !rtx_equal_p (operands[3], operands[4])" Very minor, but the file generally puts conditions on a single line if they'll fit. Same for the relaxed version. > + "@ > + movprfx\t%0., %1/z, %3.\;fsubr\t%0., %1/m, %0., #%2 > + movprfx\t%0., %1/m, %3.\;fsubr\t%0., %1/m, %0., #%2 > + #" > + "&& 1" > + { > + if (reload_completed > + && register_operand (operands[4], mode) > + && !rtx_equal_p (operands[0], operands[4])) > + { > + emit_insn (gen_vcond_mask_ (operands[0], operands[3], > + operands[4], operands[1])); > + operands[4] = operands[3] = operands[0]; > + } > + else if (!rtx_equal_p (operands[1], operands[5])) > + operands[5] = copy_rtx (operands[1]); The last two lines are a hold-over from the relaxed version, where there were two predicates. There's no operand 5 in this pattern, so we should just delete the lines. Thanks, Richard