From patchwork Thu Jul 27 00:30:18 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tsukasa OI X-Patchwork-Id: 12664 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a985:0:b0:3e4:2afc:c1 with SMTP id t5csp752021vqo; Wed, 26 Jul 2023 17:30:50 -0700 (PDT) X-Google-Smtp-Source: APBJJlEpVJpfLYS+3/HovC+D2YM6HhcNDXs6iIAfkt07tNAqO53ry/YubvO0OHuvseZejUAlq7PR X-Received: by 2002:a17:906:3055:b0:98d:63c5:d147 with SMTP id d21-20020a170906305500b0098d63c5d147mr478991ejd.47.1690417850114; Wed, 26 Jul 2023 17:30:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690417850; cv=none; d=google.com; s=arc-20160816; b=Qf8Vx9i+SWbTQ15Ypxd+cmIs21ufrcOKj4LpzYz85sOVATw4sF5L1sODE6vmue4Om9 giKrujFFHkgmlE7IFHYuUbiBl/OVZEurdMeOUGTcWCOZb9o3Tp32FE4TLajyxwxL7pJR 0QsAro/cTuSAUarpfuOY5hob8bQdx+U7+YktqrZ19yKwKscBxZ8cKdQPzX1r/5/NszKH ozmu3xRuw0QdiSzTSU9aFOdipFseqwKDt7DPtHSSimlM5LL/5dhaITNCT8pLifU/8sKU zwGBXimCrlUvV5nPdqDJl6ZncSztPGUynBalr3ZQvYeCyFzVHp9PfBLf1/yf3uOCtOEe sMnA== 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=HrA0P6fPqvPNS2d0hXQXtHWZ4qN5FimybkT8ZzI7QvU=; fh=oLBbkpKGrMjsAiDUocfN7mW0LEnMJsqDdFE8uCs7/vo=; b=oB/WMUrilTBuFjCvMAOeFvpg6tWiBpi6fTmK48n93Mk4h9hcCf7FEc9IQqUnJLg2VI RibiQEuOR/iLO1QIWcaMvXsftbjT/1VRIxVRAKfyTkiVHKyV4oumQ5C1VksiaFqb/i4c bpBp/Je+z6BDe7MPtyrCUT1k19YLU0I+7eIQPeZPPxrn41T/vVZcLwL+pmMPymA9qVwC C232VsQ81lDReANKK8p9pSfTB3rjHGnN2yWX15Do+G2Tmy+3oermLrl1hUt23J+IPJoM MEBNfKMw3ii5xKEDw3gmuh3q89Rgs9n3z8dWng7OoU/Vd2S5ta9AY0kiusGXgVrANNVJ 0kSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=w00PuN5D; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 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 (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id by23-20020a170906a2d700b00993321873fesi94475ejb.665.2023.07.26.17.30.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jul 2023 17:30:50 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=w00PuN5D; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 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 29C6D385AF97 for ; Thu, 27 Jul 2023 00:30:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29C6D385AF97 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1690417848; bh=HrA0P6fPqvPNS2d0hXQXtHWZ4qN5FimybkT8ZzI7QvU=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=w00PuN5DgBkKRq4o8972BgXNwPAoczJfuZdduXFw/bdy/s89ZJCCHxMaISg9I0UhQ I5TLZdW5mlFaxLGyn5Ap4Kl10m6p5ZuzYLYrIwboW89MED3aUYXZCJQuwPA3bMrQVp Tf4pEClcghFxUrJ8H777u8IJK/1Thr9B71LeBwDA= 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 84C8B3858C2F for ; Thu, 27 Jul 2023 00:30:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 84C8B3858C2F Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 9FDE1300089; Thu, 27 Jul 2023 00:30:29 +0000 (UTC) To: Tsukasa OI , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu , Kito Cheng Cc: binutils@sourceware.org Subject: [RFC PATCH 0/3] RISC-V: Add complex extension implications (incl. 'C'+'[FD]') Date: Thu, 27 Jul 2023 00:30:18 +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, T_SCC_BODY_TEXT_LINE autolearn=ham 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: 1772531587654011994 X-GMAIL-MSGID: 1772531587654011994 Hi, This patch set reflects rather complex implications derived from 'C' and either 'F' or 'D'. [PATCH 1-2] They are the expansions related in this context: 'C' == 'C' + 'Zca' 'C' + 'F' == 'C' + 'Zca' + 'Zcf' + 'F' (RV32) 'C' + 'F' == 'C' + 'Zca' + 'F' (RV64) 'C' + 'F' + 'D' == 'C' + 'Zca' + 'Zcf' + 'Zcd' + 'F' + 'D' (RV32) 'C' + 'F' + 'D' == 'C' + 'Zca' + 'Zcd' + 'F' + 'D' (RV64) (they exclude dependencies from 'F' and 'D') I first thought implementing this is hard (as the implication list get more complex). However, thanks to the commit 48558a5e5471 ("RISC-V: Allow nested implications for extensions"), things got a lot easier (we have an option to rescan the implication list). I haven't depended on this looping behavior in *this* patch set but this loop will be useful in the future. All we have to do is: 1. Give more information to "check_func" when checking an implied extension and 2. Implement custom "check_func" for such conditions. "check_implicit_for_d_c" corresponds to the implication 'D' -> 'Zcd' and returns true if the extension 'C' is *also* available. It makes following expansions: 1. 'C' == 'C' 2. 'C' + 'D' == 'C' + 'Zcd' + 'D' "check_implicit_for_f_c" (which corresponds to the implication 'F' -> 'Zcf') depends on "check_implicit_for_d_c" but does extra XLEN check (returns true only when XLEN == 32). It makes following expansions: 1. 'C' == 'C' 2a. 'C' + 'F' == 'C' + 'Zcf' + 'F' (RV32) 2b. 'C' + 'F' == 'C' + 'F' (RV64) Existing "check_implicit_always" does following expansion: 1. 'C' == 'C' + 'Zca' With all three combined, we can get the full expansions I listed above. [PATCH 3] It also requires some changes to the ".option norvc" half-deprecated (or completely deprecated?) compatibility directive in the assembler. I stated that it disables the 'C' extension and its subsets ('Zca', 'Zcf' and 'Zcd'). If some extensions depend on 'C' or 'Zc*' are enabled, we cannot emit compressed instructions but some garbage will remain in the RISC-V attributes and mapping symbols. Quick Example: .attribute arch, "rv32i" .option rvc .option arch, +zcb # ... .option norvc # The final architecture string will contain 'Zcb' (not disabled by # the ".option norvc" directive) and 'Zca' ('Zcb' depends on it). [Others may need this change] For instance, the draft 'Zicfiss' extension in the RISC-V CFI specification draft might need this kind of complex implications. This is because, not only the instructions in that extension depends on the existence of compressed instructions, uncompressed/compressed encodings of the extension depend on 'Zimop' (uncompressed) and 'Zcmop' (compressed), respectively. cf. (for 'Zicfiss') (for 'Zimop' and 'Zcmop') 'Zicfiss'-related dependency: * 'Zicfiss' (uncompressed encodings) -> 'Zimop' * 'Zicfiss' (compressed encodings) -> 'Zcmop' -> 'Zca' (compressed forms must be enabled when either 'C' or 'Zca' is enabled.) Example implementing the dependency using complex implications (assuming this patch set is applied): 1. 'Zicfiss' -> 'Zimop' 2. 'Zicfiss' + 'Zca' -> 'Zcmop' (check 'Zca' in custom "check_func") 3. 'Zcmop' -> 'Zca' [My Thoughts] I had to modify some test cases that use ".option arch, -c" to disable compressed instructions because ".option arch, -c" alone will not turn off its subsets. It suggests that this kind of behavior might be possibly breaking on some programs. We should monitor the situation and investigate existing programs to minimize breaking others' work. That's why this patch set is now an RFC (despite that it's ready for the upstream merge; especially PATCH 1). Thanks, Tsukasa Tsukasa OI (3): RISC-V: Base for complex extension implications RISC-V: Add complex implications from 'C'+'[DF]' RISC-V: ".option norvc" to disable 'C' and subsets bfd/elfxx-riscv.c | 66 +++++++++++++++---- gas/config/tc-riscv.c | 6 +- gas/testsuite/gas/riscv/attribute-10.d | 2 +- .../gas/riscv/dis-addr-overflow-32.d | 2 +- .../gas/riscv/dis-addr-overflow-64.d | 2 +- gas/testsuite/gas/riscv/dis-addr-overflow.s | 4 +- gas/testsuite/gas/riscv/mapping-symbols.d | 22 +++---- gas/testsuite/gas/riscv/mapping.s | 48 +++++++------- gas/testsuite/gas/riscv/march-imply-c-d-32.d | 6 ++ gas/testsuite/gas/riscv/march-imply-c-d-64.d | 6 ++ gas/testsuite/gas/riscv/march-imply-c.d | 6 ++ gas/testsuite/gas/riscv/march-ok-reorder.d | 2 +- gas/testsuite/gas/riscv/option-arch-01.s | 4 +- gas/testsuite/gas/riscv/option-arch-01b.d | 2 +- gas/testsuite/gas/riscv/option-arch-02.d | 2 +- gas/testsuite/gas/riscv/option-arch-02.s | 4 +- gas/testsuite/gas/riscv/option-arch-03.d | 2 +- gas/testsuite/gas/riscv/option-arch-03.s | 4 +- 18 files changed, 125 insertions(+), 65 deletions(-) create mode 100644 gas/testsuite/gas/riscv/march-imply-c-d-32.d create mode 100644 gas/testsuite/gas/riscv/march-imply-c-d-64.d create mode 100644 gas/testsuite/gas/riscv/march-imply-c.d base-commit: 513c7e5f3e859be8670c7aa7aae41f78f860918f