From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id C58E5385696D for ; Thu, 7 Jul 2022 02:57:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C58E5385696D Received: by mail-ed1-x535.google.com with SMTP id fd6so21464363edb.5 for ; Wed, 06 Jul 2022 19:57:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WBqSGzNvJ7I2gM8X6KzqMrFiogFM98Lu3fH0pi6Emgw=; b=32rIyKk3mLWnOGAWS+Q18Igqx20lhVqVGcer53XAVpq+qCm2JW4uKJs38sOI22wHSK uVJpLeg0J/XBMaMa87a1qWi3jNTK9m70ZCwvIvbIYk36eVMnFPgNchzkmwiQXFJLn+8Y 9ETfIm72E96IVcwz4JL2RAByDh4UC4t+0d3wY17lMSvz3dCO7dadK16vAZtERg8e5r5u iRoHjHVH92+7+UZ4VdPwjtx5zJls6kcCPFReBQCOQhtmXerLKvre/tIaiekUh0GW0Z4a NrmhV0qzM5+w7dmh+S+3wjxmOr54T1jjLB1LeUEz+VZSWkLxPzWeRGHCV7Vd3JJpQMQA XYNQ== X-Gm-Message-State: AJIora/cjdcYp+Eachg7gTH28fy25aL6sit8Fq63Tr6JsMtEVjqnZXsx wDa7m0DQU7t7HI7/vF0lYUc71uNmK6ilYxCLDFw= X-Google-Smtp-Source: AGRyM1sdpxpmzVTPi6ckhWH76mW9jD5bEWmByfPMd7KJGbCfT2Z+KUn1jGAEKC6DpYWdiW4tgoArZLLcctQCyJPsSIE= X-Received: by 2002:a05:6402:28c3:b0:43a:6d78:1b64 with SMTP id ef3-20020a05640228c300b0043a6d781b64mr22845570edb.93.1657162651472; Wed, 06 Jul 2022 19:57:31 -0700 (PDT) MIME-Version: 1.0 References: <20220627020348.11920-1-research_trasio@irq.a4lg.com> <20220627020348.11920-4-research_trasio@irq.a4lg.com> In-Reply-To: From: Kito Cheng Date: Thu, 7 Jul 2022 10:57:19 +0800 Message-ID: Subject: Re: [PATCH v2 3/8] RISC-V: Add Zfhmin/Zhinxmin (with refactoring) To: Andrew Waterman , Tsukasa OI , Nelson Chu Cc: Kito Cheng , Weiwei Li , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Thu, 07 Jul 2022 02:57:34 -0000 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.