From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 663893858D32 for ; Thu, 7 Jul 2022 06:10:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 663893858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-ej1-x62f.google.com with SMTP id j22so4348753ejs.2 for ; Wed, 06 Jul 2022 23:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AwQpWPIBQhaA/N9O5R+8wfpsveRybI9b5Ho9i4nEHWs=; b=jrlsNSc0V4I7xnnTx5eio5XuPj4AjcnTRT0/xILROMY+U+m+CMHZnXGAl7CFeWgxgG tRbBJAOZ1cETz7Kw40XowmsbvDR4K9KWkwr45xNNHeU8blsBFJzaB798xJw52wH4iDRh 9fCmi3tY2EvPvcSil6Kt6Q8VzEctf0UrdAkBAgUZ1H5/2e50Mx0a+jHiEfuz5LQ+JfCC wi32i/JBnf6FKA5n3C3hdSHZ28FimEvzr7C1+/nlg0MNCUMm9FLCtsN7cI2SygC0/fqh ZA7ObQrKxSL70xNg8FIl54Tte4C1JBAeb8EE6Qx/9hPMPq5VSyyRGaQsrsH33ziIhiYU yL9w== 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=AwQpWPIBQhaA/N9O5R+8wfpsveRybI9b5Ho9i4nEHWs=; b=DkhWlK+Ikbn6hhlvu5GDjW0BvJFvzMhvf1MxJ4Un5clurcd+cf6jHl6g0dU8uc57BQ jn9EvCj1SNq/B0VQ5RRKpmtAnPrsbRcujP8FwQ63tpiTHf5FpSJMkWBqrgn6Vjh+lrN5 sf3qXPouu2t/pvtzAVgQCGLo3lErj1LLRB2yWuv7yZZXRsxP6ajD+tZeFBvUXY/WWQKG LCyfR2qfLlo2xnTaVwYSQ1hetMAcunNzLFR9PbsbMe4ZuX8vzcZ5yna8OeM/dA2ySjn7 OTZLvodBFfn/UlSuMvl3ly7nVlYq2YSropVUWriVMN18Smlo/jX2U3Azw91Hml4LjMp7 19BA== X-Gm-Message-State: AJIora9ZmJf9BOmA2iMunF5ugz05IPaMx1Zoi5JaoABATqVOkAp+kooU yZhyjeKNXIFyjc3SDEMgfZCM+v1WxRvnLXTk X-Google-Smtp-Source: AGRyM1tNyl6yjDH1wj2RTDsjoz8iyB8Gv1fDUqD0RsrJ2WkduZ8sgEN0LW6euyrlbrkXkgbyNOxoAg== X-Received: by 2002:a17:906:31d9:b0:726:a68b:b666 with SMTP id f25-20020a17090631d900b00726a68bb666mr43507956ejf.159.1657174218648; Wed, 06 Jul 2022 23:10:18 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id p19-20020aa7cc93000000b0042bdb6a3602sm26836262edt.69.2022.07.06.23.10.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jul 2022 23:10:18 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id u12-20020a05600c210c00b003a02b16d2b8so10108544wml.2 for ; Wed, 06 Jul 2022 23:10:17 -0700 (PDT) X-Received: by 2002:a05:600c:3788:b0:3a0:4279:5142 with SMTP id o8-20020a05600c378800b003a042795142mr2273930wmr.21.1657174217466; Wed, 06 Jul 2022 23:10:17 -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: Andrew Waterman Date: Wed, 6 Jul 2022 23:10:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/8] RISC-V: Add Zfhmin/Zhinxmin (with refactoring) To: Kito Cheng Cc: Tsukasa OI , Nelson Chu , Kito Cheng , Weiwei Li , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 06:10:22 -0000 On Wed, Jul 6, 2022 at 7:57 PM 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 SGTM, the symmetry argument works for me. > > 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.