From patchwork Tue Aug 8 03:17:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tsukasa OI X-Patchwork-Id: 13282 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp1850479vqr; Mon, 7 Aug 2023 20:18:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG6VTZUN28WO0CYQG1Nm2iOCe/+uSLtvZiL1Dt4MgNlhI5bjue9gmeEnuTjX2/FK+7keTqY X-Received: by 2002:a17:906:74d7:b0:99b:c778:d46d with SMTP id z23-20020a17090674d700b0099bc778d46dmr11311090ejl.75.1691464688633; Mon, 07 Aug 2023 20:18:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691464688; cv=none; d=google.com; s=arc-20160816; b=VtDwlewVI4D936gEt4L8hQv5vIm4IyD7xC4pMSf5ndyxLvBVNzJ8ge8BkOc5KM6d71 o2OAPgA07k0+YYkY4a2nureysC9tpcWtHBLOL85t8D1aTLwyb8H75hHCPIcCIXVHnABR rufqJj2YhdwQStTG24l7epS5if9pWEh7PoJ7lVC3zdc5KlbrVv0T+92OtA8wTroVJZXu NIT/jG8ILgryXcqxkTDwoVSHGnoGkTyyokbwwIGF+fbBioqd/CsUXPEJ4WnA5sGY782p +LNxCibkrFHN3wLwN3TOfcA1zEh9U/JF4XNl7sFqBfKcWlfd4MveaqgBhk6Dud7KV/u6 sQlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=2gO077UY4h6PI9B1q7GDWf06OkOze/7o3e3fSPXdWFo=; fh=oLBbkpKGrMjsAiDUocfN7mW0LEnMJsqDdFE8uCs7/vo=; b=OmsTk4K/B5y/lQah93W2o94+J7VQ+jQ7aZX941icRQlQh7Y8dycjN2uM1c41vb7reB /zMGMWO3Bmeh3k9uo9mwdqbjl8dZG/9naA5x5V0nNiYvVkn2RcV5JmXmlV7SkgX2PLkj Kb+d2JzVX2IHRUF6F9jQdXadPLRI89LW9xiXsr+qnSp3WCpBtw0ygDA0lusZcULZr5Wp cQS8fr53gtZIa2D972jo9MsdI1ZIf/PXeOlQpR2iuMfwQV5AmH1jiNiTd3RRPadl1x3i O4nOM+r2nOL1lxgOU0J8uQfGLDLugVBXNzfqP11NBzOhNsBFJS4tSuQMKwIl/fVY2QRH /cfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=PWZtAzcY; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id r16-20020a17090638d000b00987a0569370si6204040ejd.703.2023.08.07.20.18.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 20:18:08 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=PWZtAzcY; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5435D3858433 for ; Tue, 8 Aug 2023 03:18:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5435D3858433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1691464687; bh=2gO077UY4h6PI9B1q7GDWf06OkOze/7o3e3fSPXdWFo=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=PWZtAzcYN1ziM9OmMjgT754Uro2jGVuhobt+ao0NYemA6r2+gwqw+6ExeU2RFs73p iDVjs1poPEl7jsUTkmzj6EFk5+hVhcyqfQalh+16T3EPIqQZz0idfWvny1AZbR5mlf zCCNhNuH3z+JlANKqDGJjumSnRrRAwn0NzfVo9PA= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 84F0F3858D33 for ; Tue, 8 Aug 2023 03:17:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 84F0F3858D33 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 7B9D5300089; Tue, 8 Aug 2023 03:17:55 +0000 (UTC) To: Tsukasa OI , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu , Kito Cheng Cc: binutils@sourceware.org Subject: [RFC PATCH 0/2] RISC-V: Add 'Zicntr' and 'Zihpm' support with compatibility measures Date: Tue, 8 Aug 2023 03:17:44 +0000 Message-ID: Mime-Version: 1.0 X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_MANYTO, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Tsukasa OI via Binutils From: Tsukasa OI Reply-To: Tsukasa OI Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773629276894695925 X-GMAIL-MSGID: 1773629276894695925 Hi, The role of this patch set is very simple: implement recently ratified 'Zicntr' (basic counters and timers) and 'Zihpm' (hardware performance counters) extensions, formerly a part of the 'I' extension, version 2.0. Since some draft extensions depend on those extensions, implementing counter extensions (as a part of data structure) is becoming mandatory. However, we need to be *very* careful to the implementation. Because CSRs and pseudoinstructions for those extensions were a part of 'I' and more importantly, the first version which separated counters from the 'I' extension, did not give counters extension names. So, we needed to implement such CSRs and pseudoinstructions as a part of 'I' (continuously). Not breaking the compatibility here is vital (the only exception might be the new ratified ISA after version 20191213). So, I implemented those extensions not to break anything as possible. The basic idea is, an extension (riscv_subset_t) with an unknown version is not emitted to an object file (ELF attributes, mapping symbols etc...). The default mode for existing ISAs is the compatibility mode (Option 1). [Option 1: Compatibility Mode] In the compatibility mode (as default), 1. 'I' implies 'Zicntr' and 'Zihpm'. 2. 'Zicntr' and 'Zihpm' DO NOT imply 'Zicsr'. 3. 'Zicntr' and 'Zihpm' don't have version information. (2.) is the point. The ratified document says 'Zicntr' and 'Zihpm' depend on the 'Zicsr' extension but if we do it unconditionally, that would mean that the 'I' extension indirectly depends on 'Zicsr' (because of 1.), making a difference from the ratified 'I' extension version 2.1. In order to keep the compatibility, making 'Zicntr' and 'Zihpm' against the documentation was (sadly) necessary. In the compatibility mode, code like: > riscv_subset_supports(&rps, "zicntr") will return true. Because, even that the version information is missing, the 'Zicntr' extension exists in the riscv_subset_list_t. But an extension with no version means, it will not be a part of the architectural string emitted as a part of an object file. [Option 2: Compliant Mode] We can continue this forever but we have another option. Break false dependency when a new ISA (with its version) is ratified and in that time, require those extensions separately like -march=..._zicntr_zihpm. In the compliant mode: 1. 'I' DOES NOT imply 'Zicntr' and 'Zihpm'. 2. 'Zicntr' and 'Zihpm' DO imply 'Zicsr'. 3. 'Zicntr' and 'Zihpm' have its version information (ratified version 2.0 or possibly a later version) Note that (1.) and (2.) are very opposite from the compatibility mode. In this mode, it is compliant to the specification completely. [Implementing an Option on future ISAs] Assume that we have a new ISA specification class, ISA_SPEC_CLASS_2024XXXX. We can choose which option to implement as follows. [Option 1: Compatibility Mode] 1. Change the contents of check_implicit_compat_counter_from_i. > /* Old. */ > return *rps->isa_spec <= ISA_SPEC_CLASS_20191213; > /* New. */ > return *rps->isa_spec <= ISA_SPEC_CLASS_2024XXXX; Note that the reason we are looking for the ISA specification (instead of the version of the 'I' extension) is, the 'I' extension version 2.1 is unlikely to change even when the new ISA specification is ratified. I assume that two behaviors (option 1 and 2) share the same 'I' version 2.1. If the version of the 'I' extension changes (even if no *actual* changes are made) in the new unprivileged ISA version, that would be a bit simpler. 2. Add following entries to riscv_supported_std_z_ext. Make sure that they don't have the version number. > /* ... */ > {"zicntr", ISA_SPEC_CLASS_2024XXXX, RISCV_UNKNOWN_VERSION, RISCV_UNKNOWN_VERSION, 0 }, /* Compat. */ > /* ... */ > {"zihpm", ISA_SPEC_CLASS_2024XXXX, RISCV_UNKNOWN_VERSION, RISCV_UNKNOWN_VERSION, 0 }, /* Compat. */ [Option 2: Compliant Mode] 1. DO NOT change the contents of check_implicit_compat_counter_from_i. 2. Add following entries to riscv_supported_std_z_ext. Make sure that they DO have the version number. > /* ... */ > {"zicntr", ISA_SPEC_CLASS_2024XXXX, 2, 0, 0 }, > /* ... */ > {"zihpm", ISA_SPEC_CLASS_2024XXXX, 2, 0, 0 }, ...and for compatibility, we need to slightly modify riscv-dis.c. The disassembler defaults to the latest non-draft ISA and there's currently no ways to change it. We need to make changes to riscv-dis.c by either: 1. Entering special compatibility mode (even on the latest ISA, enable 'Zicntr' extension ['Zihpm' is not necessary on the disassembler]) or 2. Enabling to change the ISA version from disassembler options. Like my long proposed disassembler changes: adding overridable "arch" and "priv-spec" options, we have an option to change the ISA using the disassembler option. In either case, this patch set leaves both options to implement yet supporting 'Zicntr' and 'Zihpm' extensions directly. Along with those changes (in PATCH 2), PATCH 1 makes possible to consider implication by using *more* information than before. This is practically the same as: , a patch to demonstrate how to implement the 'Zce' superset extension ('Zcf' must be implied by 'Zce' ONLY IF 'F' is ALSO enabled). The only difference is a minor type change as follows (to enable using the "riscv_subset_supports" function). * Before: "const riscv_parse_subset_t *" * After: " riscv_parse_subset_t *" Is there any other options? Should I simplify the patch assuming we choose the compatibility mode (Option 1) forever? In any case, I would like to hear your thoughts. Thanks, Tsukasa Tsukasa OI (2): RISC-V: Base for complex extension implications RISC-V: Add 'Zicntr' and 'Zihpm' support with compatibility measures bfd/elfxx-riscv.c | 86 +++++-- gas/config/tc-riscv.c | 16 ++ gas/testsuite/gas/riscv/march-imply-i.s | 8 + include/opcode/riscv-opc.h | 310 ++++++++++++------------ include/opcode/riscv.h | 1 + opcodes/riscv-opc.c | 12 +- 6 files changed, 256 insertions(+), 177 deletions(-) base-commit: d734d43a048b33ee12df2c06c2e782887e9715f6