From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=+okB=DZ=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34])
	by sourceware.org (Postfix) with ESMTP id 5ECC53858D33
	for <gcc-patches@gcc.gnu.org>; Tue,  8 Aug 2023 21:52:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5ECC53858D33
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 427BA9200C1; Tue,  8 Aug 2023 23:52:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 357869200BF;
	Tue,  8 Aug 2023 22:52:13 +0100 (BST)
Date: Tue, 8 Aug 2023 22:52:13 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jeff Law <jeffreyalaw@gmail.com>
cc: Xiao Zeng <zengxiao@eswincomputing.com>, 
    gcc-patches <gcc-patches@gcc.gnu.org>, gaofei <gaofei@eswincomputing.com>
Subject: Re: [committed][RISC-V] Fix 20010221-1.c with zicond
In-Reply-To: <37f727f2-73ea-d9ad-af62-7cc87cc2f408@gmail.com>
Message-ID: <alpine.DEB.2.21.2308082246530.38537@angie.orcam.me.uk>
References: <003943c5-c68c-0d15-8f2f-b890cd7b17e1@gmail.com> <202308041729232721253@eswincomputing.com> <37f727f2-73ea-d9ad-af62-7cc87cc2f408@gmail.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3488.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,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: <gcc-patches.gcc.gnu.org>

On Fri, 4 Aug 2023, Jeff Law via Gcc-patches wrote:

> It's also something I kept meaning to resolve and your submission just gave me
> the proper motivation to move zicond forward.  The target specific bits you
> did lined up perfectly with the community feedback on the original VRULL
> implementation as well as the direction Ventana had taken on our internal
> tree.

 I wonder however why do we need so much more code, including the middle 
end too, to support this ISA extension than we do for the very same set of 
MIPSr6 instructions under ISA_HAS_SEL, hmm...

  Maciej