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

[Andrew Waterman]

On Wed, Jul 6, 2022 at 7:57 PM Kito Cheng <kito.cheng@gmail.com> 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 <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.