From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender-0.a4lg.com [IPv6:2401:2500:203:30b:4000:6bfe:4757:0]) by sourceware.org (Postfix) with ESMTPS id 9D6B93857354 for ; Sat, 1 Oct 2022 08:26:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D6B93857354 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 0A02D300089; Sat, 1 Oct 2022 08:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1664612760; bh=C2KvZ//2b6Hhw7Xxsi6O8Ir218pm/E9cHAnZf1iu2Ko=; h=Message-ID:Date:Mime-Version:Subject:To:References:From:Cc: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=T5nz8pZje38WA5tVA53l5oQceqdytZHFa8ecmhTp4kv8n4ej3wcy9isZY2koCp7lc PXVxuecCVBpg+KiyKTW/8Mt8nde1X/KxD4EfmfO97v1853wtnqdyLuB+VtVZ5m3mA9 CXCZvHSbWCeKwmesutxDLD+DnPCw7L+qq3nMdqWE= Message-ID: <349dc99b-2e92-d1e7-0b9e-18c26f923d02@irq.a4lg.com> Date: Sat, 1 Oct 2022 17:25:57 +0900 Mime-Version: 1.0 Subject: Re: [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics Content-Language: en-US To: Nelson Chu References: From: Tsukasa OI Cc: Binutils In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP 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 2022/10/01 16:21, Nelson Chu wrote: > On Sat, Oct 1, 2022 at 1:27 PM Tsukasa OI wrote: >> >> Hi all RISC-V folks, >> >> GitHub tracker: >> >> >> While investigating possible implementation of both 'Z[fdq]inx' and 'P' >> implementations, I found something common (not just register pairs). >> >> Here, this patch implements what I call "extension variants". >> It was formerly a part of 'Zfinx' fixes (formerly the flag was named >> "INSN_F_OR_X"). >> >> If there is a instruction with multiple variants with different requirements >> and the assembler fails to parse all variants, there is a case that needs to >> refer ALL variants to generate proper diagnostics. >> >> If an instruction with "INSN_HAS_EXT_VARS" fails on all variants, the >> assembler now has a chance to modify the instruction class for proper >> diagnostics. A typical use of this feature is to select wider instruction >> class when necessary. >> >> >> [Usage: CLZ instruction ('Zbpbo')] >> >> To implement proposed 'Zbpbo' extension, updating instruction class for >> CLZ instruction is not enough. If we change CLZ instruction class from >> "INSN_CLASS_ZBB" to "INSN_CLASS_ZBB_OR_ZBPBO", we will **mistakenly** >> support that instruction on RV64_Zbpbo because CLZ on 'Zbpbo' is RV32-only. >> >> Possible use with "INSN_HAS_EXT_VARS" is to define two variants of CLZ >> instruction with that flag: >> >> 1. 'Zbb' (RV32/RV64) >> 2. 'Zbpbo' (RV32) > > Will we write an extra entry for clz can resolve the problem? > > {"clz", 32, INSN_CLASS_ZBPBO, ... > {"clz", 0, INSN_CLASS_ZBB, ... > > Nelson I initially thought so but it turned out that it cannot. I learned it when I splitted D/Zdinx and Q/Zqinx. If an instruction entry is not matched because an extension is missing, information to store missing extension is stored before trying the next variant. The point here is, this information is _overwritten_ when not matched and only the last one is used to generate the error message when all variants are not matched. So (on environment with -march=rv32i with no 'Zbb' or 'Zbpbo'), just placing two entries like that results in the message saying 'Zbb' is required ('Zbpbo' is going to be ignored). That's why something has to change (and I think that this is the one of the simplest solution). Thanks, Tsukasa > >> If both fails, we can widen the instruction class from "INSN_CLASS_ZBPBO" >> to "INSN_CLASS_ZBB_OR_ZBPBO" if XLEN is 32. >> After doing that, we will get following diagnostics: >> >> - On RV32: 'Zbb' or 'Zbpbo' is required >> - On RV64: 'Zbb' is required >> >> >> [Usage: 'D'/'Zdinx' or 'Q'/'Zqinx'] >> >> Due to use of register pairs, we need to split 'D'/'Q' and 'Zdinx'/'Zqinx' >> variants. For instance, if parsing "fmin.d" fails on both 'D' and 'Zdinx' >> variants, we have to require 'D' or 'Zdinx', not just 'Zdinx', the last >> "fmin.d" variant in riscv_opcodes. >> >> 1. 'D' >> 2. 'Zdinx' >> >> If both fails, we can widen the instruction class from "INSN_CLASS_ZDINX" to >> "INSN_CLASS_D_OR_ZDINX". >> After doing that, we will get diagnostics saying 'D' or 'Zdinx' is required. >> >> >> >> Thanks, >> Tsukasa >> >> >> >> >> Tsukasa OI (1): >> RISC-V: Implement extension variants >> >> gas/config/tc-riscv.c | 27 +++++++++++++++++++++++++-- >> include/opcode/riscv.h | 5 +++++ >> 2 files changed, 30 insertions(+), 2 deletions(-) >> >> >> base-commit: b4477c7f666bdeb7f8e998633c7b0cb62310b9ef >> -- >> 2.34.1 >> >