Re: [Qemu-devel] [PATCH] tests/tcg: add float_madds test to multiarch

2019-09-14 Thread Richard Henderson
On 9/14/19 1:59 PM, Alex Bennée wrote:
> 
> Richard Henderson  writes:
> 
>> On 9/13/19 9:49 AM, Alex Bennée wrote:
>>> +/* must be built with -O2 to generate fused op */
>>> +r = a * b + c;
>>
>> I would prefer to use fmaf() or __builtin_fmaf() here.
>>
>> Although you'll need to link with -lm just in case the
>> target doesn't support an instruction for fmaf and so
>> the builtin expands to the standard library call.
> 
> I can do that - we have other tests that link to libm.
> 
> I was expecting to see more breakage but the ppc64 tests all passed (or
> at least against the power8 David ran it on). What am I missing to hit
> the cases you know are broken?

I would *expect* the test to pass when run natively on power8 hardware.  Did it
not fail when run via qemu?  If not, then we didn't really choose the argument
sets that are affected by double rounding.

I would expect the inputs that Paul used in the original report to be
candidates.  Otherwise, we should grab some from the glibc fma test case(s).

> I've also experimented with reducing the number of iterations because if
> we want to have golden references we probably don't want to dump several
> hundred kilobytes of "golden" references into the source tree.
> 
>> I also like Paul's suggestion to use hex float constants.
> 
> Hmm I guess - look a bit weird but I guess that's lack of familiarity.
> Is is still normalised? I guess the frac shows up (without the implicit
> bit).

The implicit bit is there: 0x1.xxx.  The representation is always normalized;
you write denormal numbers by using an exponent that would require 
denormalization.


r~



Re: [Qemu-devel] [PATCH] tests/tcg: add float_madds test to multiarch

2019-09-14 Thread Alex Bennée


Richard Henderson  writes:

> On 9/13/19 9:49 AM, Alex Bennée wrote:
>> +/* must be built with -O2 to generate fused op */
>> +r = a * b + c;
>
> I would prefer to use fmaf() or __builtin_fmaf() here.
>
> Although you'll need to link with -lm just in case the
> target doesn't support an instruction for fmaf and so
> the builtin expands to the standard library call.

I can do that - we have other tests that link to libm.

I was expecting to see more breakage but the ppc64 tests all passed (or
at least against the power8 David ran it on). What am I missing to hit
the cases you know are broken?

I've also experimented with reducing the number of iterations because if
we want to have golden references we probably don't want to dump several
hundred kilobytes of "golden" references into the source tree.

> I also like Paul's suggestion to use hex float constants.

Hmm I guess - look a bit weird but I guess that's lack of familiarity.
Is is still normalised? I guess the frac shows up (without the implicit
bit).

>
>
> r~


--
Alex Bennée



Re: [Qemu-devel] [PATCH] tests/tcg: add float_madds test to multiarch

2019-09-14 Thread Richard Henderson
On 9/13/19 9:49 AM, Alex Bennée wrote:
> +/* must be built with -O2 to generate fused op */
> +r = a * b + c;

I would prefer to use fmaf() or __builtin_fmaf() here.

Although you'll need to link with -lm just in case the
target doesn't support an instruction for fmaf and so
the builtin expands to the standard library call.

I also like Paul's suggestion to use hex float constants.


r~



Re: [Qemu-devel] [PATCH] tests/tcg: add float_madds test to multiarch

2019-09-13 Thread Paul Clarke
On 9/13/19 8:49 AM, Alex Bennée wrote:
> +static float f32_numbers[] = {
> +-SNANF,
> +-NAN,
> +-INFINITY,
> +-FLT_MAX,
> +-1.111E+31,
> +-1.111E+30,
> +-1.08700982e-12,
> +-1.78051176e-20,
> +-FLT_MIN,
> +0.0,
> +FLT_MIN,
> +2.98023224e-08,
> +5.96046E-8, /* min positive FP16 subnormal */
> +6.09756E-5, /* max subnormal FP16 */
> +6.10352E-5, /* min positive normal FP16 */
> +1.0,
> +1.0009765625, /* smallest float after 1.0 FP16 */
> +2.0,
> +M_E, M_PI,
> +65503.0,
> +65504.0, /* max FP16 */
> +65505.0,
> +131007.0,
> +131008.0, /* max AFP */
> +131009.0,
> +1.111E+30,
> +FLT_MAX,
> +INFINITY,
> +NAN,
> +SNANF
> +};

I've noticed that Glibc prefers to use hex representation for float values, to 
ensure an accurate representation.  If you care to do so, here they are:
static float f32_numbers[] = {
-SNANF, 
-NAN,   
-INFINITY,
-FLT_MAX,
-0x1.1874b2p+103,
-0x1.c0bab6p+99,
-0x1.31f75p-40,
-0x1.505444p-66,
-FLT_MIN,
0.0,
FLT_MIN,
0x1p-25,
0x1.e6p-25, /* min positive FP16 subnormal */
0x1.ff801ap-15, /* max subnormal FP16 */
0x1.0cp-14, /* min positive normal FP16 */
1.0,
0x1.004p+0, /* smallest float after 1.0 FP16 */
2.0,
M_E, M_PI,
0x1.ffbep+15,
0x1.ffcp+15, /* max FP16 */
0x1.ffc2p+15,
0x1.ffbfp+16,
0x1.ffcp+16, /* max AFP */
0x1.ffc1p+16,
0x1.c0bab6p+99,
FLT_MAX,
INFINITY,
NAN,
SNANF   
};

PC