This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend

> On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
>> I think it would make sense to have a check list of properties, and
>> use configure-based tests to categorize implementations. These tests
>> would be added as we go along.
>> Criteria:
>> [ ] Conforms to C99 for exceptional values 
>>     (accepting/producing NaNs, infinities)
> C is not the only language. Other languages (e.g. Java) may have
> different rules. And IEEE 754-2008 also specifies different rules.
> And you may want to consider LIA-2 too, which is again different...

True, but I tried to keep the number of criteria small. Actually, 
my main interest here is allowing conformance with the Ada standard,
see chapter G.2 
so I'm not looking at this with a "C-only" mindset. :-)

However, even though the Ada requirements are different, it would
still be tremendously helpful to be able to rely on the C99 standard,
and then just deal with other cases separately. But yes, we might
want to include even more configurability.

>> [ ] Handles non-standard rounding modes,
>>     trapping math, errno, etc.
> By "non-standard rounding modes", I assume you mean "non-default
> rounding modes".
Yes, indeed.
>> [ ] Meets certain relative error bounds,
>>     copy from Ada Annex G numerical requirements
>>     (typically between 2 eps and 4 eps for much of range)
> FYI, OpenCL also has numerical requirements.
They seem similar, though only apply to single precision,
while the rules defined by Ada are parametrized by type.
Where OpenCL specifies an error as 4 ulps, Ada specifies a
relative error of 2 epsilon. For values just below a
power of 2, 2 epsilon equals 4 ulps, while for values 
just above they are ulps and eps are equivalent.
So, the Ada requirements are a bit tighter in general.
Probably we can define something that is the union
of both sets of requirements. 

>> [ ] Guaranteed error less than 1 ulp over all arguments,
>>     typical max. error close to 0.5 ulp.
> Instead, I would say faithful rounding (this is slightly stricter
> for results close to powers of 2).
Yes, that is better.
>> [ ] Correctly rounded for all arguments
> I would add:
>   [ ] Symmetry (e.g. cos(-x) = cos(x), sin(-x) = - sin(x)) in the
>       symmetric rounding modes.
>   [ ] Monotonicity (for monotonous functions).
> (note that they are implied by correct rounding).
Right, my goal was to have just a few different buckets that fit
well with GCC compilation options and allow categorization of 
existing functions. 

I guess, it should be a few check boxes and a numerical level.
This would be a categorization for source code, not compiled
code where me might have additional copies based on optimization


  [ ]  Conforms to C99 for exceptional values 
       (accepting/producing NaNs, infinities)

  [ ]  Handles non-default rounding modes,
       trapping math, errno, etc.

  [ ]  Requires IEEE compliant binary64 arithmetic
       (no implicit extended range or precision)

  [ ]  Requires IEEE compliant binary80 arithmetic
       (I know, not official format, but YKWIM)
Accuracy level:

  0 - Correctly rounded

  1 - Faithfully rounded, preserving symmetry and monotonicity

  2 - Tightly approximated, meeting prescribed relative error
      bounds. Conforming to OpenCL and Ada Annex G "strict mode"
      numerical bounds.

  3 - Unspecified error bounds

Note that currently of all different operating systems we (AdaCore)
support for the GNAT compiler, I don't know of any where we can rely
on the system math library to meet level 2 requirements for all
functions and over all of the range! Much of this is due to us 
supporting OS versions as long as there is vendor support, so while 
SPARC Solaris 9 and later are fine, Solaris 8 had some issues. 
GNU Linux is quite good, but has issues with the "pow" function for
large exponents, even in current versions, and even though Ada
allows a relative error of (4.0 + |Right · log(Left)| / 32.0) 
for this function, or up to 310 ulps at the end of the range.
Similarly, for trigonometric functions, the relative error for 
arguments larger than some implementation-defined angle threshold
is not specified, though the angle threshold needs to be at
least radix**(mantissa bits / 2), so 2.0**12 for binary32 or 2.0**32
for binary80. OpenCL doesn't specify an angle threshold, but I
doubt they intend to require sufficient accurate reduction over
the entire range to have a final error of 4 ulps: that doesn't fit
with the rest of the requirements.

The Ada test suite (ACATS) already has quite extensive tests for (2),
which are automatically parameterized for any type (including those
with non-binary radix). That, and the fact that this level apparently
is still a challenge for most system math libraries seems like a good
reason for aiming for this level as a base level.

We should consider any libm function not meeting these minimal 
criteria to be buggy (or: only usable with -ffast-math, if actually fast),
and use a replacement. We could have -fstrict-math select the most
accurate functions we have, with the actual level being more for 
documentation purposes than anything else.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]