This is the mail archive of the
mailing list for the GCC project.
Re: Fourth Draft "Unsafe fp optimizations" project description.
- To: <moshier at moshier dot ne dot mediaone dot net>, "Toon Moene" <toon at moene dot indiv dot nluug dot nl>
- Subject: Re: Fourth Draft "Unsafe fp optimizations" project description.
- From: "Tim Prince" <tprince at computer dot org>
- Date: Sun, 12 Aug 2001 21:48:44 -0700
- Cc: <gcc at gcc dot gnu dot org>
- References: <Pine.LNX.firstname.lastname@example.org>
----- Original Message -----
From: "Stephen L Moshier" <email@example.com>
To: "Toon Moene" <firstname.lastname@example.org>
Sent: Sunday, August 12, 2001 7:29 AM
Subject: Re: Fourth Draft "Unsafe fp optimizations" project
> > However, for `sin' and `cos' this is different; the
> > not be as accurate for all inputs as their library
> > I mention this issue below under "Open issues", because I
> > have no idea how to deal with this.
> Sine and cosine instructions are implemented for arm,
> and m68k targets. They give high precision if the argument
> though m68k loses several bits in XFmode. They might not
> C99 for IEEE special value inputs. Otherwise, the
> be used safely if one knew that the user program was
> reduction with sufficient accuracy.
> The loss of accuracy is due to subtractive cancellation, an
> that your document does not mention. The coprocessor
> is something like
> x - pi * floor(x / pi)
> in which two nearly equal values are subtracted but at least
> them is inexact. Associative law rearrangements can
> a total loss of precision due to cancellation error.
The internal value of pi is not exact, but it should have 66
bits of significance, on any processor model of the last 7
years, so it is difficult for a user program to perform much
more accurate range reduction. The one commonly used range
reduction based on i386 internals which is deficient is the
one used in exp(), where glibc takes the short cut in its
external function and does not necessarily get more than float