From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender-0.a4lg.com [IPv6:2401:2500:203:30b:4000:6bfe:4757:0]) by sourceware.org (Postfix) with ESMTPS id 5A0DD384604C for ; Sun, 5 Jun 2022 04:43:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A0DD384604C Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 7D6F8300089; Sun, 5 Jun 2022 04:43:10 +0000 (UTC) From: Tsukasa OI To: Tsukasa OI , Palmer Dabbelt , Kito Cheng , Nelson Chu , Weiwei Li Cc: binutils@sourceware.org Subject: [PATCH 0/2] RISC-V: QUICK fix on Li's Zhinx implementation Date: Sun, 5 Jun 2022 13:43:06 +0900 Message-Id: Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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-List-Received-Date: Sun, 05 Jun 2022 04:43:14 -0000 Hello, I understand that my Zfinx fixes + Zfhmin/Zhinxmin patchset requires some time to review. Meanwhile, there's a quick fix to Li's Zhinx implementation. My patchset already contains equivalent fix but I extracted the most important one (that should definately be fixed before 2.39). My combined float patchset: Li Weiwei's Zhinx implementation: PATCH 1: Again, this is a duplicate of: (in my combined fixes) PATCH 2 required a test to give -march including **both** Zqinx and Zhinx. As a result, this patch is mandatory for the next patch is to be applied. Otherwise, it would need likely non-canonical ordering on -march. PATCH 2: Following instructions have INSN_CLASS_D_AND_ZFH_INX: - fcvt.h.d - fcvt.d.h Following instructions have INSN_CLASS_Q_AND_ZFH_INX: - fcvt.h.q - fcvt.q.h I noticed that feature gates on those instruction classes are most likely incorrect. Quoting ISA Manual 24.5 "Zhinxmin": > If the Zdinx extension is present, the FCVT.D.H and FCVT.H.D > instructions are also included. Although no such limitation is explicitly specified on "Zhinx" itself, it's very unlikely that FCVT.D.H and FCVT.H.D can be supported without Zdinx extension. Quoting Manual 16.3 "Half-Precision Conversion and Move Instructions" from Zfh: > If the D extension is present, FCVT.D.H or FCVT.H.D converts a half- > precision floating-point number to a double-precision floating-point > number, or vice-versa, respectively. If the Q extension is present, > FCVT.Q.H or FCVT.H.Q converts a half-precision floating-point number > to a quad-precision floating-point number, or vice-versa, > respectively. And 24.4 "Zhinx": > The Zhinx extension adds all of the instructions that the Zfh > extension adds, except for the transfer instructions FLH, FSH, > FMV.H.X, and FMV.X.H. The Zhinx variants of these Zfh-extension > instructions have the same semantics, except that (cont...) On INSN_CLASS_D_AND_ZFH_INX: Li's implementation : (D && Zfh) || Zhinx This patch : (D && Zfh) || (Zdinx && Zhinx) My combined float patchset : (D && Zfhmin) || (Zdinx && Zhinxmin) This commit fixes feature gates and their diagnostics. Thanks, Tsukasa Tsukasa OI (2): RISC-V: Add 'H' to canonical extension ordering RISC-V: Fix requirement handling on Zhinx+{D,Q} bfd/elfxx-riscv.c | 32 +++++++++++++++++++----- gas/testsuite/gas/riscv/fp-zhinx-insns.d | 2 +- 2 files changed, 27 insertions(+), 7 deletions(-) base-commit: c8eab1d7c92ad72089c98e5753ebc96419e3674a -- 2.34.1