[Qemu-devel] QEMU support for IEEE 754-201x minimumNumber/maximumNumber

[Michael Clark]

Hi Folks,

I'm currently going through riscv-tests failures in riscv-qemu and we have
an issue with fmin/fmax.

In particular, this test case is failing:

- https://github.com/riscv/riscv-tests/blob/master/isa/rv64uf/fmin.S#L35-L35

The RISC-V port is currently using the solftfloat floatXX_minnum/maxnum
methods which implement IEEE 754-2008 minNum/maxNum.

RISC-V depends on the IEEE 754-201x definition of
minimumNumber/maximumNumber which returns x for fminmax(sNaN, x) whereas
QEMU implements IEEE 754-2008 minNum/maxNum and will return x, for
fminmax(qNaN, x) but will return NaN for fminmax(sNaN, x)

minNum(x, y) is defined as
- min(x, y) if neither is NaN
- if one of x and y is a number and one is qNaN, return the number
- if both are qNaN, or either is sNaN, return NaN

minimumNumber(x, y) is defined as
- min(x, y) if neither is NaN
- if one of x and y is a number and one is qNaN or sNaN, return the number
- if both are NaN, return the number

My question. Should we add support for minimumNumber/maximumNumber in
fpu/softfloat.c or just implement private versions of these intrinsics in
target/riscv/fpu_helper.c

If we were to change core code, we'd have to think about the interface to
the common min/max macro. i.e. instead of having the ieee flag, have
ieee2008 and ieee201x flags.

The least risk approach would be to define a macro
in target/riscv/fpu_support.c, and then later consider moving it to core
code.

Does the fpu/softfloat.c code have good test coverage in make check?

Michael.