[PATCH] Optimized generic expf and exp2f

[Szabolcs Nagy]

Based on new expf and exp2f code from
https://github.com/ARM-software/optimized-routines/

with https://sourceware.org/ml/libc-alpha/2017-08/msg01126.html
expf reciprocal-throughput: 3.3x faster
expf latency: 1.7x faster
libm.so size: -8byte data, -2140byte text
expf/exp2f worst case nearest rounding ulp error: 0.502

Error checks are inline and actual error handling is
in separate functions that are tail called and expected
to be reusable when other math functions are implemented
without wrappers. (expf, __expf, __ieee754_expf symbols
are aliases, _LIB_VERSION is not checked, errno is set
unconditionally according to POSIX rules.)

Double precision arithmetics is used which is expected
to be faster on most targets (including soft-float) than
using single precision and it is easier to get good
precision result with it.

Const data is kept in a separate translation unit which
complicates maintenance a bit, but is expected to give
good code for literal loads on most targets and allows
sharing data across expf, exp2f and powf.

Some configuration is in a new math_config.h which is
currently kept similar to the one in optimized-routines
repo which had to be self-contained, I expect that this
will need more adjustments for glibc.

Some details may need target specific tweaks:
- best convert and round to int operation in the arg
reduction may be different across targets.
- code was optimized on fma target, optimal polynomial
eval may be different without fma.
- gcc does not always generate good code for fp bit
representation access via unions or it may be inherently
slow on some target.

One issue with the argument reduction is that it only
works right with nearest rounded rint, otherwise the
interval is [0,2c] or [-2c,0] instead of [-c,c]. The
polynomial is optimized for [-c,c] but it has sufficent
extra precision that it gives acceptable results on
[-2c,2c] too assuming users are less interested in
non-nearest rounded precision, however this means some
glibc ulp error limits will need adjustment.

Another issue is with the polynomial evaluation which
causes 1 ulp errors for tiny inputs in some non-nearest
rounding, but i think it is worth the trade off for
better pipelined polynomial.


2017-09-05  Szabolcs Nagy  <szabolcs.nagy@arm.com>

	* math/Makefile (type-float-routines): Add math_errf and e_exp2f_data.
	* sysdeps/ieee754/flt-32/w_expf_compat.c: Move to...
	* math/w_expf_compat.c: ... here.
	* sysdeps/aarch64/fpu/math_private.h (TOINT_INTRINSICS): Define.
	(roundtoint, converttoint): Likewise.
	* sysdeps/ieee754/flt-32/e_expf.c: New implementation.
	* sysdeps/ieee754/flt-32/e_exp2f.c: New implementation.
	* sysdeps/ieee754/flt-32/e_exp2f_data.c: New file.
	* sysdeps/ieee754/flt-32/math_config.h: New file.
	* sysdeps/ieee754/flt-32/math_errf.c: New file.
	* sysdeps/ieee754/flt-32/w_exp2f_compat.c: New file.
	* sysdeps/x86_64/fpu/w_expf_compat.c: New file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expf.diff
Type: text/x-patch
Size: 24259 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170905/aa9c1ac5/attachment.bin>