i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs

David Schultz das at FreeBSD.ORG
Sun Feb 13 10:10:36 PST 2005

The following reply was made to PR i386/67469; it has been noted by GNATS.

From: David Schultz <das at FreeBSD.ORG>
To: Bruce Evans <bde at zeta.org.au>
Cc: FreeBSD-gnats-submit at FreeBSD.ORG, freebsd-i386 at FreeBSD.ORG,
	bde at FreeBSD.ORG
Subject: Re: i386/67469: src/lib/msun/i387/s_tan.S gives incorrect results for large inputs
Date: Sun, 13 Feb 2005 13:08:37 -0500

 On Mon, Feb 14, 2005, Bruce Evans wrote:
 > It seems that the hardware trig functions aren't worth using.  I want
 > to test them on a 486 and consider the ranges more before discarding
 > them.  This may take a while.
 Fair enough.  I would be happy to have a hybrid implementation
 that uses the hardware only when appropriate.  However, your 486
 benchmarks notwithstanding, I would just as soon rely on fdlibm
 entirely for the trig functions.  It just doesn't seem worthwhile
 to me, given that the only parts of the domain where the hardware
 is faster *and* correct are, roughly speaking, [0,2^-28) and
 > I did a quick test of some other functions:
 > - hardware sqrt is much faster
 > - hardware exp is slightly faster on the range [1,100]
 > - hardware atan is slower on the range [0,1.5]
 > - hardware acos is much slower (139 nsec vs 57 nsec!) on the range [0,1.0].
 sqrt isn't transcendental, so it should be faster and correctly
 rounded on every hardware platform.  I found similar results to
 yours for atan() and acos() when writing amd64 math routines, but
 of course amd64 has the overhead of switching between the SSE and
 i387 units.  Maybe they should go away, too...

More information about the freebsd-i386 mailing list