From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 762723858D1E for ; Sat, 1 Oct 2022 05:27:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 762723858D1E 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 B433F300089; Sat, 1 Oct 2022 05:27:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1664602053; bh=boaD8HR09b8CGvu9i9EAnve7538B7hHTBPPmfRNyJSs=; h=From:To:Cc:Subject:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=QFNobJjZkVkb51bVGdtkV0vAXMRRuGCG2WvGLKEfwB0c98A9vAQxyzz95YB597F4n m1+1e8/ij7KKnQVI+6qSE8LaR7XJL1jj+Hu7lHNnxSwK9+P6OQv9Iix/AekSLTKFWl A5AIGFo7ENNGHAspszxQ35V4rxS5HFoQLB6c7/hk= From: Tsukasa OI To: Tsukasa OI , Nelson Chu , Kito Cheng , Palmer Dabbelt Cc: binutils@sourceware.org Subject: [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics Date: Sat, 1 Oct 2022 05:27:30 +0000 Message-Id: Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 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: 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) 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