[PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps

[Andrew Waterman]

On Mon, Jul 13, 2020 at 2:59 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 13 Jul 2020, Carlos O'Donell via Libc-alpha wrote:
>
> > > If results on QEMU and on hardware (for the same binaries) don't match,
> > > that indicates a bug in one or the other, which you could find by
> > > identifying the exact instruction at which different floating-point values
> > > first appear.  (You can get different results from compilation with
> > > different options or compiler versions, however, without any such bug,
> > > because of e.g. changes in when the compiler chose to contract an
> > > expression to use fused multiply-add.)
> >
> > Is it really a "bug?" QEMU as an emulator could be taking liberties that
> > the hardware does not for the express purpose of improving emulated
> > performance? Is it ever QEMU's contract that it will operate identically
> > to hardware given the same software configuration?
>
> I believe the semantics of the RISC-V floating-point instructions are
> fully specified (including details such as choice of NaN results) and so
> it's a bug for either hardware or emulator to produce results other than
> those in the architecture specification.
>
> Sometimes architecture specifications do not fully specify results for all
> floating-point instructions.  For example, the Power instructions to
> estimate reciprocal or reciprocal square root have accuracy bounds in the
> architecture specification, but the exact result is not specified, so it
> would be legitimate for hardware and emulation to produce different
> results for those instructions.  But AArch64 has an instruction to
> estimate reciprocal square root whose exact semantics are fully specified
> in the architecture specification, meaning it's a bug if emulation fails
> to produce a result with exactly the same bit-pattern as hardware.  My
> understanding is that all the RISC-V floating-point instructions are fully
> specified, as on AArch64.

This is indeed the case (at least for now; the forthcoming vector
extension adds an unordered sum reduction whose result can vary by
implementation).  I think it would be good to confirm whether the
exact same binaries were used for the QEMU and Unleashed experiments,
and if not, whether the disparity remains when that's rectified.

>
> --
> Joseph S. Myers
> joseph@codesourcery.com