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

[Kito Cheng]

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 <andrew@sifive.com> 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
> <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.