[Bug math/13932] dbl-64 pow unexpectedly slow for some inputs

["wdijkstr at arm dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13932

Wilco <wdijkstr at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wdijkstr at arm dot com

--- Comment #15 from Wilco <wdijkstr at arm dot com> ---
(In reply to Vincent Lefèvre from comment #12)
> (In reply to cvs-commit@gcc.gnu.org from comment #11)
> >     Remove slow paths from pow
> 
> Instead of removing the slow paths, wouldn't have been better to fix the bug
> (see comment #10, where the slowness cannot be explained by the correct
> rounding, since this is an easy case), then decide?

Removing buggy code is far better than fixing it...

(In reply to Vincent Lefèvre from comment #13)
> From the bug report, it is __ieee754_pow_sse2 that was used, and if I
> understand correctly, the code is in "sysdeps/x86_64/fpu/multiarch/e_pow.c",
> which uses "sysdeps/ieee754/dbl-64/e_pow.c". The slow path would imply that
> __exp1 returns a non-positive value. __exp1 is defined in
> "sysdeps/ieee754/dbl-64/e_exp.c". There, the rounding test is:
> 
>       if (res == (res + cor * (1.0 + error + err_1)))
> 
> For the example of slow case pow(0.562500, 1.5), the exact result is
> 0.421875 = 27/64, so that cor should be much smaller than ulp(res) and a
> positive value should be returned, which doesn't explain the behavior.

Whenever you're close to 0.5 ULP, cor will be just below 0.5ULP, eg.
0.4999999999, so any value of error + err_1 that is larger than 2^-53ULP will
cause it to round up, thus falling into the slow path.

-- 
You are receiving this mail because:
You are on the CC list for the bug.