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 799593858D1E for ; Wed, 2 Aug 2023 10:06:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 799593858D1E 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 D6730113E; Wed, 2 Aug 2023 03:06:44 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 993E13F6C4; Wed, 2 Aug 2023 03:06:00 -0700 (PDT) From: Richard Sandiford To: Jeff Law via Gcc-patches Mail-Followup-To: Jeff Law via Gcc-patches ,Xiao Zeng , research_trasio@irq.a4lg.com, kito.cheng@gmail.com, zhengyu@eswincomputing.com, eri-sw-toolchain@eswincomputing.com, Jeff Law , richard.sandiford@arm.com Cc: Xiao Zeng , research_trasio@irq.a4lg.com, kito.cheng@gmail.com, zhengyu@eswincomputing.com, eri-sw-toolchain@eswincomputing.com, Jeff Law Subject: Re: [PATCH 2/5] [RISC-V] Generate Zicond instruction for basic semantics References: <20230719101156.21771-1-zengxiao@eswincomputing.com> <20230719101156.21771-3-zengxiao@eswincomputing.com> Date: Wed, 02 Aug 2023 11:05:59 +0100 In-Reply-To: (Jeff Law via Gcc-patches's message of "Wed, 2 Aug 2023 00:22:55 -0600") 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=-20.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Jeff Law via Gcc-patches writes: > On 8/1/23 05:18, Richard Sandiford wrote: >> >> Where were you seeing the requirement for pointer equality? genrecog.cc >> at least uses rtx_equal_p, and I think it has to. E.g. some patterns >> use (match_dup ...) to match output and input mems, and mem rtxes >> shouldn't be shared. > It's a general concern due to the way we handle transforming pseudos > into hard registers after allocation is complete. We can end up with > two REG expressions that will compare equal according to rtx_equal_p, > but which are not pointer equal. But isn't that OK? I don't think there's a requirement for match_dup pointer equality either before or after RA. Or at least, there shouldn't be. If something happens to rely on pointer equality for match_dups then I think we should fix it. So IMO, like you said originally, match_dup would be the right way to handle this kind of pattern. The reason I'm interested is that AArch64 makes pretty extensive use of match_dup for this purpose. E.g.: (define_insn "aarch64_abd" [(set (match_operand:VDQ_BHSI 0 "register_operand" "=w") (minus:VDQ_BHSI (USMAX:VDQ_BHSI (match_operand:VDQ_BHSI 1 "register_operand" "w") (match_operand:VDQ_BHSI 2 "register_operand" "w")) (:VDQ_BHSI (match_dup 1) (match_dup 2))))] So if this isn't working correctly for subregs (or for anythine else), then I'd be keen to do something about it :) I don't want to labour the point though. Thanks, Richard