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 1DDB9385B534 for ; Mon, 13 Feb 2023 17:32:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1DDB9385B534 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=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 7A6D74B3; Mon, 13 Feb 2023 09:33:03 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B705F3F703; Mon, 13 Feb 2023 09:32:19 -0800 (PST) From: Richard Sandiford To: Andrew Pinski via Gcc-patches Mail-Followup-To: Andrew Pinski via Gcc-patches ,Philipp Tomsich , Andrew Pinski , Kito Cheng , Christoph Muellner , Palmer Dabbelt , Andrew Waterman , Vineet Gupta , richard.sandiford@arm.com Cc: Philipp Tomsich , Andrew Pinski , Kito Cheng , Christoph Muellner , Palmer Dabbelt , Andrew Waterman , Vineet Gupta Subject: Re: [RFC PATCH v1 08/10] ifcvt: add if-conversion to conditional-zero instructions References: <20230210224150.2801962-1-philipp.tomsich@vrull.eu> <20230210224150.2801962-9-philipp.tomsich@vrull.eu> Date: Mon, 13 Feb 2023 17:32:18 +0000 In-Reply-To: (Andrew Pinski via Gcc-patches's message of "Fri, 10 Feb 2023 15:07:22 -0800") 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=-29.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP 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: Andrew Pinski via Gcc-patches writes: > On Fri, Feb 10, 2023 at 2:47 PM Philipp Tomsich > wrote: >> >> Some architectures, as it the case on RISC-V with the proposed >> ZiCondOps and the vendor-defined XVentanaCondOps, define a >> conditional-zero instruction that is equivalent to: >> - the positive form: rd = (rc != 0) ? rs : 0 >> - the negated form: rd = (rc == 0) ? rs : 0 >> >> While noce_try_store_flag_mask will somewhat work for this case, it >> will generate a number of atomic RTX that will misdirect the cost >> calculation and may be too long (i.e., 4 RTX and more) to successfully >> merge at combine-time. > > Can you expand on this? Especially when there are patterns that use > (if_then_else) already. > >> >> Instead, we add two new transforms that attempt to build up what we >> define as the canonical form of a conditional-zero expression: >> >> (set (match_operand 0 "register_operand" "=r") >> (and (neg (eq_or_ne (match_operand 1 "register_operand" "r") >> (const_int 0))) >> (match_operand 2 "register_operand" "r"))) > > Again why are you not using: > (set (reg) (if_then_else (eq_ne (reg) (const_int 0)) (reg) (const_int 0))) > Form instead of the really bad "canonical" form of the above? I don't think one form is inherently better than the other if we think about just this one case. But I agree that the if_then_else form is currently the canonical form for the operation, and extends more naturally to the general case. AArch64 already matches specifically for it (with xzr providing the zero value). Thanks, Richard