From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 53EAA3858D39 for ; Wed, 2 Aug 2023 06:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53EAA3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3a74d759be4so1082810b6e.2 for ; Tue, 01 Aug 2023 23:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690957379; x=1691562179; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PIHap3lzveByyaZ6Y/gI960kjWYjlL2CFozTAvFc0M4=; b=n2mqK3PK4CGEuOpF/Bq8PoNw1G7pPl8Vhb1+KuHs07Ai5YRewUmNYgz7MXW4xmmERv vcYP6RBWf7XF9rdAyztsIk1LLUwM9k78PjaBLANC74NaFL9VPB79h9SCPpx4rbiXYLmf RpgWDQtHuukiphBPD7yHlfmVE3Gc+uYleAlZ8a91lx1GtjcQ6SnpXL40sUFJsW0b7shB wdIlqaQeYFB9U9SpNGYmcdUM7n9dMTMVdedZMq5ofUs6nX3H6KxmF4BmAS/fkr9237yz q/hqSbV7H2u2m9b6rz9b+2RHD1n1jUaR0AjYj/iBRW8eWO4YlcgFWE6/ESPCHu/986SL R6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690957379; x=1691562179; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PIHap3lzveByyaZ6Y/gI960kjWYjlL2CFozTAvFc0M4=; b=aZaH0SCYskn62/1ly+24JfkKXpmt1Bs3GHX2zwzHZMQRzKFtTJvLww0l6+J8FUPD/w K1/dBmdTgOQhcpXLE5VML5PwwN8eeUKhsXHprdsC5q9jHfy8TRixcXZBjz4RmtwGnPqu kh163lRdqOKouHRdv0fNwZUYRR6oKGWvafkeAxvNbuBHKOtKSn5xFm5kT6GwsLevtJxe NDC4BJcl/R46W4gQM1WLc7JVApAyy2kyIdGPFRWlDmmGjKIcGBklq08gBRRZzYPD2kLe SD/kv1Td1cWPhXB7OUCXXMs1FJHgTUs/enmDX1SiYreFMjqjsWZ0Oj6tPYrcqc9laBsj rGRQ== X-Gm-Message-State: ABy/qLYp60GTORkNv48QqNxYxNlCmJ7FzlM64qHu5ArkhPuYndj9Lh3x kvROaud1Zp3TPRaa90YK0rtMdruqzuQZ9g== X-Google-Smtp-Source: APBJJlFy2bLY6QOEoGYYuFsimfVUzKJ+9RoxCmG9kAxAmZbH2CQOT+yxNRq+ysnDY1XSHnRgG8kAyg== X-Received: by 2002:a05:6808:3a7:b0:3a0:4636:d095 with SMTP id n7-20020a05680803a700b003a04636d095mr14245079oie.59.1690957378813; Tue, 01 Aug 2023 23:22:58 -0700 (PDT) Received: from [172.31.1.103] ([172.56.168.109]) by smtp.gmail.com with ESMTPSA id h8-20020a17090a470800b0025bfda134ccsm443099pjg.16.2023.08.01.23.22.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Aug 2023 23:22:58 -0700 (PDT) Message-ID: Date: Wed, 2 Aug 2023 00:22:55 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 2/5] [RISC-V] Generate Zicond instruction for basic semantics Content-Language: en-US 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, richard.sandiford@arm.com References: <20230719101156.21771-1-zengxiao@eswincomputing.com> <20230719101156.21771-3-zengxiao@eswincomputing.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. For this kit I think the worst that would happen would be a failure to optimize cases post-reload. But it's still good RTL hygene IMHO. > > I'd always understood using matching constraints against other inputs > to be a no-no, since the RA doesn't (and can't reasonably be expected to) > make two non-identical inputs match. So AIUI, using "1" won't lead to > different code generation compared to "r". Both are relying on the RA > happening to do the right thing. But "1" would presumably trigger an > ICE if something goes wrong. Yea, I think you're right. The constraint isn't terribly important for these patterns -- the condition is really the enforcement mechanism. Jeff