tile: create new math-tests.h header

  The header makes tile use the new mechanisms for suppressing
exception and rounding support (the ROUNDING_TESTS_xxx() and
EXCEPTION_TESTS_xxx macros).  More importantly, it also now sets
SNAN_TESTS_PRESERVE_PAYLOAD to 0, since the tile soft float does
not preserve NaN payloads.
---
This change fixes the math/test-{,i}{double,float} failures.

2016-11-16  Chris Metcalf  <cmetcalf@mellanox.com>

	* sysdeps/tile/math-tests.h: New file.

 sysdeps/tile/math-tests.h | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 sysdeps/tile/math-tests.h
  

On Wed, 16 Nov 2016, Chris Metcalf wrote:

> The header makes tile use the new mechanisms for suppressing
> exception and rounding support (the ROUNDING_TESTS_xxx() and
> EXCEPTION_TESTS_xxx macros).  More importantly, it also now sets
> SNAN_TESTS_PRESERVE_PAYLOAD to 0, since the tile soft float does
> not preserve NaN payloads.

All the tile sfp-machine.h files in libgcc seem to define _FP_KEEPNANFRACP 
to 1, so not preserving NaN payloads seems odd here.
  

On 11/16/2016 5:51 PM, Joseph Myers wrote:
> On Wed, 16 Nov 2016, Chris Metcalf wrote:
>
>> The header makes tile use the new mechanisms for suppressing
>> exception and rounding support (the ROUNDING_TESTS_xxx() and
>> EXCEPTION_TESTS_xxx macros).  More importantly, it also now sets
>> SNAN_TESTS_PRESERVE_PAYLOAD to 0, since the tile soft float does
>> not preserve NaN payloads.
> All the tile sfp-machine.h files in libgcc seem to define _FP_KEEPNANFRACP
> to 1, so not preserving NaN payloads seems odd here.

So perhaps it's some kind of testing bug, or I'm otherwise
confused.  The following small program seems to suggest
that the payload is copied in canonicalize.  I built it naively just
by compiling it with my system headers but linking statically
against "libc.a math/libm.a" in the glibc build tree.  It prints
out "0 nan nan 1 1" when run.

#include <stdio.h>
#include <math.h>

double getpayload (const double *x);
int canonicalize (double *__cx, const double *__x);

int main()
{
   const double nan = __builtin_nans("0x1");
   double nan_payload = getpayload(&nan);
   double cnan;
   int rc = canonicalize(&cnan, &nan);
   double cnan_payload = getpayload(&nan);

   printf("%d %a %a %g %g\n", rc, nan, cnan, nan_payload, cnan_payload);
   return 0;
}
  

On Thu, 17 Nov 2016, Chris Metcalf wrote:

> > All the tile sfp-machine.h files in libgcc seem to define _FP_KEEPNANFRACP
> > to 1, so not preserving NaN payloads seems odd here.
> 
> So perhaps it's some kind of testing bug, or I'm otherwise
> confused.  The following small program seems to suggest

Indeed, you'll need to investigate why the test fails in more detail.  
(The rest of your math-tests.h generically makes sense for any system 
without exceptions / rounding modes support.)
  

On 11/17/2016 6:28 PM, Joseph Myers wrote:
> On Thu, 17 Nov 2016, Chris Metcalf wrote:
>
>>> All the tile sfp-machine.h files in libgcc seem to define _FP_KEEPNANFRACP
>>> to 1, so not preserving NaN payloads seems odd here.
>> So perhaps it's some kind of testing bug, or I'm otherwise
>> confused.  The following small program seems to suggest
> Indeed, you'll need to investigate why the test fails in more detail.
> (The rest of your math-tests.h generically makes sense for any system
> without exceptions / rounding modes support.)

I drilled into libm-test enough to create a single reproducer, which
then inspired me to go back to look at the little test program I
emailed yesterday, which turned out to have had a typo.  Oh well.

In any case, the hardware on tilegx appears not to preserve the
payload when you add nans of any kind, so we see this manifest in the
code for canonicalize(__builtin_nans) only because that's the only
case where we actually ask the hardware to do some math for us.

We clearly should also tell libgcc not to bother preserving nan
payloads given that the hardware doesn't do it in any case; I'll pass
that along to the compiler team, but I'll also commit my original
patch since it seems to match the hardware behavior.

Thanks!
  

On Fri, 18 Nov 2016, Chris Metcalf wrote:

> We clearly should also tell libgcc not to bother preserving nan
> payloads given that the hardware doesn't do it in any case; I'll pass
> that along to the compiler team, but I'll also commit my original
> patch since it seems to match the hardware behavior.

FWIW, I wouldn't expect any significant performance difference between 
copying a payload and setting a payload to the canonical one (which is 
what you get if !_FP_KEEPNANFRACP).
  

On 11/18/2016 1:11 PM, Joseph Myers wrote:
> On Fri, 18 Nov 2016, Chris Metcalf wrote:
>
>> We clearly should also tell libgcc not to bother preserving nan
>> payloads given that the hardware doesn't do it in any case; I'll pass
>> that along to the compiler team, but I'll also commit my original
>> patch since it seems to match the hardware behavior.
> FWIW, I wouldn't expect any significant performance difference between
> copying a payload and setting a payload to the canonical one (which is
> what you get if !_FP_KEEPNANFRACP).

My assumption was that we should tweak it for consistency, not for
performance.  Is your sense that we might as well keep the NaN
payloads in libgcc even if we don't with inline float operations?
  

On Fri, 18 Nov 2016, Chris Metcalf wrote:

> On 11/18/2016 1:11 PM, Joseph Myers wrote:
> > On Fri, 18 Nov 2016, Chris Metcalf wrote:
> > 
> > > We clearly should also tell libgcc not to bother preserving nan
> > > payloads given that the hardware doesn't do it in any case; I'll pass
> > > that along to the compiler team, but I'll also commit my original
> > > patch since it seems to match the hardware behavior.
> > FWIW, I wouldn't expect any significant performance difference between
> > copying a payload and setting a payload to the canonical one (which is
> > what you get if !_FP_KEEPNANFRACP).
> 
> My assumption was that we should tweak it for consistency, not for
> performance.  Is your sense that we might as well keep the NaN
> payloads in libgcc even if we don't with inline float operations?

Consistency with hardware is logical (I think the reason for such hooks in 
soft-fp is to allows its use in Linux kernel floating-point emulation to 
behave the same as the hardware being emulated).  Note however that when 
soft-fp creates a default NaN it also gives it a default sign - if that's 
what you want for consistency with hardware, you'll need a new 
math-tests.h hook for these canonicalize tests to disregard the sign of 
the result as well as its payload.
  

On 11/18/2016 4:18 PM, Joseph Myers wrote:
> On Fri, 18 Nov 2016, Chris Metcalf wrote:
>
>> On 11/18/2016 1:11 PM, Joseph Myers wrote:
>>> On Fri, 18 Nov 2016, Chris Metcalf wrote:
>>>
>>>> We clearly should also tell libgcc not to bother preserving nan
>>>> payloads given that the hardware doesn't do it in any case; I'll pass
>>>> that along to the compiler team, but I'll also commit my original
>>>> patch since it seems to match the hardware behavior.
>>> FWIW, I wouldn't expect any significant performance difference between
>>> copying a payload and setting a payload to the canonical one (which is
>>> what you get if !_FP_KEEPNANFRACP).
>> My assumption was that we should tweak it for consistency, not for
>> performance.  Is your sense that we might as well keep the NaN
>> payloads in libgcc even if we don't with inline float operations?
> Consistency with hardware is logical (I think the reason for such hooks in
> soft-fp is to allows its use in Linux kernel floating-point emulation to
> behave the same as the hardware being emulated).  Note however that when
> soft-fp creates a default NaN it also gives it a default sign - if that's
> what you want for consistency with hardware, you'll need a new
> math-tests.h hook for these canonicalize tests to disregard the sign of
> the result as well as its payload.

Good point, but, the hardware does preserve the sign of NaN's, so
just disabling the payload testing is sufficient for the tests to pass.

I think we may just leave the payload copying enabled in soft-fp
unless you think it's a bad choice; it seems harmless and arguably
might give us better results in some circumstances.
  

On Mon, 21 Nov 2016, Chris Metcalf wrote:

> I think we may just leave the payload copying enabled in soft-fp
> unless you think it's a bad choice; it seems harmless and arguably
> might give us better results in some circumstances.

I think it's harmless to leave it as-is.