From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 0E32D3856DC6 for ; Sat, 1 Oct 2022 07:21:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E32D3856DC6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-1318106fe2cso7832165fac.13 for ; Sat, 01 Oct 2022 00:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=/ysvDSbA3iQoipu3a8JWC7ZEns/YIXCJ2HiWuQL46nQ=; b=iPZdMlGTphJUZT2hxYgWovQGE8EA/nwFRghbKRXfFPSVDb3uFsqFb5DwUB+Uj+9F+Y PqCz/ydjHFTwL840BYAUyxyPsxkBeiqPXeZZVKRAeWAIQmIKGHYuzwGRe7jS4Sr6Ax5c micKrkXI3TGi/i4uUShghSIrPSRbQgmL35STFia2PE4ig2vsQiKAP0U86w6l1IHqToQr ROEa+6E8KXUVhVmgJ7kQQE3Tu0/4obxc2II4V6BmAqlFPQEfpkhm4UDCzDfNmP9JuNP4 sSsyFGoiIOjVdz3mlWJ7KstwFU3AVNFZf9tC5JlYiMVoh9CgWRk75PHAkjjLQt+b6LHA LORA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=/ysvDSbA3iQoipu3a8JWC7ZEns/YIXCJ2HiWuQL46nQ=; b=WiIt1vpuRnD5Qb8l0PZQaVkBZJt0X4pfScbSQ7hM4d8UOXc08WrpcnPl0RL3f2xqGc bVeIBjRlYR+fmorYChiNAmYTQxBIAXrp8sAVskCIfaFFtYy+UwUKRXd4UQq+dZ/pXC8R owyNMc7R9Gz/kvVz7+sdePJWpP4k7mB8NTOah+/TqtJXD6xbog4gYPAMjRQirhmiGxjC 7zJa6jd7z+s1F8jjCLqdpIZEe02SQIEBDnPjb3OTPesC3jHgozacdyaH+IafBO/T+obO jd2B2VCP3QbW9xI3/gtcnAZnlgmlPpgwRH0pA/+MDBfWgzWIhT0wFjlyMlyK8b5EUPX2 pU+w== X-Gm-Message-State: ACrzQf0eDjpwmQ3Wf9qcJl+J000+TkTgaTfrjbgAdhyGftTOL5nA4CpW WJ81AtJCyvKeyrybBRGXuuNIXWUyveR5N2wL6ZMISg== X-Google-Smtp-Source: AMsMyM4HK5XV5Up8fVLa1voiQe19tTddjLCNGOeJ4GveOFXMnIf1PwPRb5rzM1lo98VzqLQSFeYwWOa88aCmltHb+vE= X-Received: by 2002:a05:6870:507:b0:130:ae8d:db0e with SMTP id j7-20020a056870050700b00130ae8ddb0emr879921oao.82.1664608897459; Sat, 01 Oct 2022 00:21:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nelson Chu Date: Sat, 1 Oct 2022 15:21:26 +0800 Message-ID: Subject: Re: [RFC PATCH 0/1] RISC-V: Implement "extension variants" for diagnostics To: Tsukasa OI Cc: Kito Cheng , Palmer Dabbelt , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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 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 > 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 >