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 4EDBB3858C2C for ; Fri, 8 Jul 2022 05:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4EDBB3858C2C Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 5197D300089; Fri, 8 Jul 2022 05:37:56 +0000 (UTC) Message-ID: Date: Fri, 8 Jul 2022 14:37:53 +0900 Mime-Version: 1.0 Subject: Re: [PATCH v2 3/8] RISC-V: Add Zfhmin/Zhinxmin (with refactoring) Content-Language: en-US To: Nelson Chu Cc: Andrew Waterman , Kito Cheng , Weiwei Li , Binutils References: <20220627020348.11920-1-research_trasio@irq.a4lg.com> <20220627020348.11920-4-research_trasio@irq.a4lg.com> From: Tsukasa OI In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 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: Fri, 08 Jul 2022 05:38:01 -0000 On 2022/07/07 13:43, Nelson Chu wrote: > I cannot just use "git am" for this patch, there are too many > conflicts. Am I doing something wrong? No, you are doing right. I submitted two Zfinx-related patchsets: - Quicker patchset - Larger patchset You merged all functional part of quicker one's patches and some of larger patchset but they were intended to be mutually exclusive (if quicker one is merged first, I was going to rebase larger patchset and submit it). I will rebase remaining patches (from larger patchset) and submit later (to make merging [for GNU Binutils 2.40] smoother). Thanks, Tsukasa > > On Thu, Jul 7, 2022 at 10:57 AM Kito Cheng wrote: >> >> Hi Andrew: >> >> The sound makes sense to me, but personally I would prefer to keep >> fmv.h for zfh to make that consistent with fmv.* :P >> >> Hi Tsukasa, Nelson: >> >> I am OK with the current version, and verified with GCC. >> >> On Wed, Jul 6, 2022 at 7:19 AM Andrew Waterman wrote: >>> >>> IMO, we should not add this alias for Zfhmin, reason being that it >>> would mean FMV.H has different semantics in Zfhmin vs. Zfh. >>> >>> Yes, the behavior is the same if the input is a NaN-boxed >>> half-precision number, but what if it isn't? Namely, what if the >>> programmer accidentally uses FMV.H to move a single-precision number? >>> This would work correctly when assembling for Zfhmin, but would fail >>> when assembling for Zfh. Obviously, this is a programming error, but >>> it still seems a bit unfortunate to me. >>> >>> (In fact, we could consider deleting the FMV.H alias altogether--even >>> for Zfh. We would then recommend programmers and compilers always use >>> FMV.S to move half-precision floating-point numbers for both Zfh and >>> Zfhmin.) >>> >>> >>> >>> On Tue, Jul 5, 2022 at 7:22 AM Kito Cheng via Binutils >>> wrote: >>>> >>>>> +{"fmv.h", 0, INSN_CLASS_ZFH_OR_ZHINX, "D,U", MATCH_FSGNJ_H, MASK_FSGNJ_H, match_rs1_eq_rs2, INSN_ALIAS }, >>>> Maybe we need one more alias for ZFHMIN? like this: {"fmv.h", 0, >>>> INSN_CLASS_ZFHMIN, "D,U", MATCH_FSGNJ_S, MASK_FSGNJ_S, >>>> match_rs1_eq_rs2, INSN_ALIAS }, >>>> >>>> --- >>>> Spec say: >>>> Zfhmin does not include the FSGNJ.H instruction, because it suffices to >>>> instead use the FSGNJ.S instruction to move half-precision values between >>>> floating-point registers. >