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 06746385BF92 for ; Wed, 1 Apr 2020 16:28:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 06746385BF92 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 911621FB; Wed, 1 Apr 2020 09:28:09 -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 8704D3F52E; Wed, 1 Apr 2020 09:28:08 -0700 (PDT) From: Richard Sandiford To: Richard Henderson Mail-Followup-To: Richard Henderson , gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com, marcus.shawcroft@arm.com, kyrylo.tkachov@arm.com, Wilco.Dijkstra@arm.com, Segher Boessenkool , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com, marcus.shawcroft@arm.com, kyrylo.tkachov@arm.com, Wilco.Dijkstra@arm.com, Segher Boessenkool Subject: Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns References: <20200321024231.13778-1-richard.henderson@linaro.org> <20200321024231.13778-4-richard.henderson@linaro.org> Date: Wed, 01 Apr 2020 17:28:07 +0100 In-Reply-To: (Richard Henderson's message of "Tue, 31 Mar 2020 15:44:51 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-15.9 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, 01 Apr 2020 16:28:11 -0000 Richard Henderson writes: > On 3/31/20 11:34 AM, Richard Sandiford wrote: >>> +(define_insn "*cmp3_carryinC" >>> + [(set (reg:CC CC_REGNUM) >>> + (compare:CC >>> + (ANY_EXTEND: >>> + (match_operand:GPI 0 "register_operand" "r")) >>> + (plus: >>> + (ANY_EXTEND: >>> + (match_operand:GPI 1 "register_operand" "r")) >>> + (match_operand: 2 "aarch64_borrow_operation" ""))))] >>> + "" >>> + "sbcs\\tzr, %0, %1" >>> + [(set_attr "type" "adc_reg")] >>> +) >> >> I guess this feeds into your reply to Segher's comment for 7/9, >> but I think: >> >> (compare:CC X Y) >> >> is always supposed to be the NZCV flags result of X - Y, as computed in >> the mode of X and Y. If so, it seems like the type of extension should >> matter. E.g. the N flag ought to be set for: >> >> (compare:CC >> (sign_extend 0xf...) >> (plus (sign_extend 0x7...) >> (ltu ...))) >> >> but ought to be clear for: >> >> (compare:CC >> (zero_extend 0xf...) >> (plus (zero_extend 0x7...) >> (ltu ...))) >> >> If so, I guess this is a bug in the existing code... > > The subject of CCmodes is a sticky one. It mostly all depends on what combine > is able to do with the patterns. > > For instance, your choice of example above, even for signed, the N bit cannot > be examined by itself, because that would only be valid for a comparison > against zero, like > > (compare (plus (reg) (reg)) > (const_int 0)) > > For this particular bit of rtl, the only valid comparison is N == V, > i.e. GE/LT. > > If we add a new CC mode for this, what would you call it? Probably not > CC_NVmode, because to me that implies you can use either N or V, but it doesn't > imply you must examine both. > > If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE > to match those patterns? Or do we add new CC modes just so that combine's use > of SELECT_CC_MODE *cannot* match them? Yeah, looks awkward. There isn't AFAICT any way to describe the full NZCV result of SBCS as a compare, in the case where C is possibly zero. So I guess if we're going to continue using compare then we need to cook up a new mode like you say. How important is it to describe the flags operation as a compare though? Could we instead use an unspec with three inputs, and keep it as :CC? That would still allow special-case matching for zero operands. Thanks, Richard