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 1F3AA385455F for ; Wed, 23 Nov 2022 08:30:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F3AA385455F 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 71DF5300089; Wed, 23 Nov 2022 08:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1669192257; bh=peyOBXtZDAvynPyUxGv4A90GDntEuxyVEkFaJ0xCa34=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: Mime-Version:Content-Transfer-Encoding; b=eZJxSpSPIpbYW/OvJStzV8OOOJZ3ItmeTRXS53OlZaaO7QjRcjH2/wEuS2ykdm7DL 2ywMWxzehKwpJEUaaPbGQ/Z3bwcyZay/dQ39XoDm2mYHnsHTbCMhMnVHUuDcKrLjm4 GYUjx8ozcIc0gGzZhKmCys4yNP5g7nRERdYxsMdY= From: Tsukasa OI To: Tsukasa OI , Jan Beulich , Nelson Chu Cc: binutils@sourceware.org Subject: [PATCH v2 0/2] RISC-V: Better support for long instructions (64 < x <= 176 [bits]) Date: Wed, 23 Nov 2022 08:30:47 +0000 Message-Id: In-Reply-To: References: 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: Hello, c.f. PATCH v1: [Changes: v1 -> v2] 1. Rebased (as usual) 2. PATCH 2/2: Simplified the logic to extract low instruction bits (will describe later) 3. PATCH 2/2: Changed the commit message slightly As a part of the process making the logic more flexible to bignum internal changes, PATCH v1 used a complex logic. After some investigation, I found the function: generic_bignum_to_int32. I decided to use this on PATCH v2. Despite that it DOES NOT guarantee that it will extract lower 32-bits of a big number even if the number overflows but it does (on the current design) and flexible enough to bignum internal changes (I don't want to make dependencies to something which can be easily changed as long as it is reasonable enough). Just for sure, I added a comment for the assumption of this part. Thanks, Tsukasa Tsukasa OI (2): RISC-V: Make .insn tests stricter RISC-V: Better support for long instructions gas/config/tc-riscv.c | 38 ++++++++++++++++++++++------ gas/testsuite/gas/riscv/insn-dwarf.d | 10 +++++++- gas/testsuite/gas/riscv/insn-na.d | 28 ++++++++++++-------- gas/testsuite/gas/riscv/insn.d | 32 +++++++++++++++++++---- gas/testsuite/gas/riscv/insn.s | 9 +++++++ opcodes/riscv-dis.c | 13 ++++++---- 6 files changed, 101 insertions(+), 29 deletions(-) base-commit: 829b6b3736d972f5fbacda09c82b31802d3b594c -- 2.38.1