libm functions sensitive to current rounding mode
enh
enh at google.com
Fri Mar 13 03:58:33 UTC 2015
various SoC vendors have been sending us (Android) assembler
implementations of various libm functions, and we noticed when looking
at one change that it was slower on certain inputs than the FreeBSD C
implementation we were already using. the response was that the cost
was coping with other rounding modes, and they gave this example:
#include <math.h>
#include <stdio.h>
#include <fenv.h>
int main(){
double x = -0xb.6365e22ee46fp4;
fesetround(FE_UPWARD);
printf("sin(%f) = %.16e\n", x, sin(x));
fesetround(FE_DOWNWARD);
printf("sin(%f) = %.16e\n", x, sin(x));
x = 0x1.921fb54442d16p0;
fesetround(FE_UPWARD);
printf("sin(%f) = %.16e\n", x, sin(x));
fesetround(FE_DOWNWARD);
printf("sin(%f) = %.16e\n", x, sin(x));
return 0;
}
see https://android-review.googlesource.com/112700 for the original
change and related conversation.
glibc 2.19:
sin(-182.212373) = -2.4759225463534308e-18
sin(-182.212374) = -2.4759225463534309e-18
sin(1.570797) = 1.0000000000000000e+00
sin(1.570796) = 1.0000000000000000e+00
(glibc's fixed bugs here in the past. see
https://sourceware.org/bugzilla/show_bug.cgi?id=3976 for example.)
the FreeBSD libm:
sin(-182.212374) = -2.4759225463534304e-18
sin(-182.212374) = 2.2575413760606011e-11
sin(1.570796) = 1.0000000000000000e+00
sin(1.570796) = 1.0000000002522276e+00
it looks like e_sqrtl.c, s_fmal.c, s_fma.c, and s_fmaf.c save/restore
the rounding mode but nothing else does.
let me know if you'd like me to send trivial patches for any of the
affected functions. (do all the libm functions need this?)
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
More information about the freebsd-numerics
mailing list