From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 4A02C385841A for ; Tue, 5 Jul 2022 23:19:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A02C385841A 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-x62a.google.com with SMTP id n4so4896762ejz.10 for ; Tue, 05 Jul 2022 16:19:21 -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=ZQx2ZG1y6lnsvb3vny/CgIs/rL7MdlXlFEfF8EUu6OE=; b=J+jOiszQDIHScO9Aabi5LtPOr2uKQk0BkKPO7idaG85QMuMRwOeKCHYGBERlr4YChp w1shIlv/gWhCjkF0yPKenGcAlbIV9hjiwC/9ohS0Zndokdx91S4XHDIPg5qTzyro2otl 9e4JO05Stg5RSsVtZv4/o1DW5FvxfZAyaBQSgfJrJ2AFblNAPpRYiiuPvLRMNBWASogJ phMq8bskVOagvOrc4dOEdu2p7RWO+lII8rMYr8TdRWoa/KI1WSJT2VMUKwotOnIO9aso r1BtReWdHrCzFaTRMYM6XSBzN0Dy+uy24SgfWiqL4bYgT0NIthxgKbF1EaL0JjBGuOku kkUg== 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=ZQx2ZG1y6lnsvb3vny/CgIs/rL7MdlXlFEfF8EUu6OE=; b=CuCQkCS+UkLjF0I7dJCsRvh/qaH5rC/cvCrMhIyaMxYgJMcm4PKczGhO9bBhjnXIC6 VrSo11p79CjPRwg+obbpL1JgAW6faHeZFrXKxEHAMohVke8wygAu8mRc0c6NUQpzMGFH /uW39W2l0pgq2Hl4+3NaG7M5NIzMkFXbkp+ftD7plPxoseGkSQ7kgJRk93yGPGOZ/Ew7 AGbmHMpNMWuXYxI7d8EdXX/AqzBdUAQuVroy6q1GvAQVeTbu6Cln7OlE4G/C7FVMljfq wZ3pNB5w1UCzvqFu2IHKDrPh8GvmvfGAHJL4rzO3XhRPNvm7p/rySS2evJQ8fA7qKgej +JpQ== X-Gm-Message-State: AJIora9vC4t+3BOhaYwgj9ZjPtLjWKCf9HmsICGM66IETF5aGWTNXi5L HVnLKsrC/LLcTsxKBufvJZzyFWZa8869hxEX X-Google-Smtp-Source: AGRyM1tMQfa0LTXvf8rtfDorRq3oGH2VpzT26qQuHxGbwVniPmsiKbFYCW8Ks7csrk4FLKjODA0ufA== X-Received: by 2002:a17:907:6d05:b0:726:a670:253 with SMTP id sa5-20020a1709076d0500b00726a6700253mr37506683ejc.23.1657063159900; Tue, 05 Jul 2022 16:19:19 -0700 (PDT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com. [209.85.221.52]) by smtp.gmail.com with ESMTPSA id e15-20020a056402104f00b0043577da51f1sm24287437edu.81.2022.07.05.16.19.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jul 2022 16:19:19 -0700 (PDT) Received: by mail-wr1-f52.google.com with SMTP id s1so19579322wra.9 for ; Tue, 05 Jul 2022 16:19:19 -0700 (PDT) X-Received: by 2002:a05:6000:83:b0:21b:a7bd:e388 with SMTP id m3-20020a056000008300b0021ba7bde388mr33751002wrx.41.1657063158765; Tue, 05 Jul 2022 16:19:18 -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: Tue, 5 Jul 2022 16:19:07 -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 , 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: Tue, 05 Jul 2022 23:19:22 -0000 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.