Re: [PATCH v2 3/8] RISC-V: Add Zfhmin/Zhinxmin (with refactoring)

[Andrew Waterman <andrew@sifive.com>]

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
<binutils@sourceware.org> 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.