with naive exp2l(x*log2e) the last 12bits of the result was incorrect
for x with large absolute value

with hi + lo = x*log2e is caluclated to 128 bits precision and then
  expl(x) = exp2l(hi) + exp2l(hi) * f2xm1(lo)
this gives <1.5ulp measured error everywhere in nearest rounding mode

__invtrigl is not needed when acosl, asinl, atanl have asm
implementations

exp(inf), exp(-inf), exp(nan) used to raise wrong flags

old: 2*atan2(sqrt(1-x),sqrt(1+x))
new: atan2(fabs(sqrt((1-x)*(1+x))),x)
improvements:
* all edge cases are fixed (sign of zero in downward rounding)
* a bit faster (here a single call is about 131ns vs 162ns)
* a bit more precise (at most 1ulp error on 1M uniform random
samples in [0,1), the old formula gave some 2ulp errors as well)

use (1-x)*(1+x) instead of (1-x*x) in asin.s
the later can be inaccurate with upward rounding when x is close to 1

the int part was wrong when -1 < x <= -0 (+0.0 instead of -0.0)
and the size and performace gain of the asm version was negligible

(fldl instruction was used instead of flds and fldt)

special care is made to avoid any inexact computations when either arg
is zero (in which case the exact absolute value of the other arg
should be returned) and to support the special condition that
hypot(±inf,nan) yields inf.

hypotl is not yet implemented since avoiding overflow is nontrivial.

the old formula atan2(1,sqrt((1+x)/(1-x))) was faster but
could give nan result at x=1 when the rounding mode is
FE_DOWNWARD (so 1-1 == -0 and 2/-0 == -inf), the new formula
gives -0 at x=+-1 with downward rounding.

the fscale instruction is slow everywhere, probably because it
involves a costly and unnecessary integer truncation operation that
ends up being a no-op in common usages. instead, construct a floating
point scale value with integer arithmetic and simply multiply by it,
when possible.

for float and double, this is always possible by going to the
next-larger type. we use some cheap but effective saturating
arithmetic tricks to make sure even very large-magnitude exponents
fit. for long double, if the scaling exponent is too large to fit in
the exponent of a long double value, we simply fallback to the
expensive fscale method.

on atom cpu, these changes speed up scalbn by over 30%. (min rdtsc
timing dropped from 110 cycles to 70 cycles.)

this is a lot more efficient and also what is generally wanted.
perhaps the bit shuffling could be more efficient...

exponents (base 2) near 16383 were broken due to (1) wrong cutoff, and
(2) inability to fit the necessary range of scalings into a long
double value.

as a solution, we fall back to using frndint/fscale for insanely large
exponents, and also have to special-case infinities here to avoid
inf-inf generating nan.

thankfully the costly code never runs in normal usage cases.

this could perhaps use some additional testing for corner cases, but
it seems to be correct.

up to 30% faster exp2 by avoiding slow frndint and fscale functions.
expm1 also takes a much more direct path for small arguments (the
expected usage case).

unlike some implementations, these functions perform the equivalent of
gcc's -ffloat-store on the result before returning. this is necessary
to raise underflow/overflow/inexact exceptions, perform the correct
rounding with denormals, etc.

unlike trig functions, these are easy to do in asm because they do not
involve (arbitrary-precision) argument reduction. fpatan automatically
takes care of domain issues, and in asin and acos, fsqrt takes care of
them for us.

infinities were getting converted into nans. the new code simply tests
for infinity and replaces it with a large magnitude value of the same
sign.

also, the fcomi instruction is apparently not part of the i387
instruction set, so avoid using it.

these are functions that have direct fpu approaches to implementation
without problematic exception or rounding issues. x86_64 lacks
float/double versions because i'm unfamiliar with the necessary sse
code for performing these operations.

a double precision nan, when converted to extended (80-bit) precision,
will never end in 0x400, since the corresponding bits do not exist in
the original double precision value. thus there's no need to waste
time and code size on this check.

the fsqrt opcode is correctly rounded, but only in the fpu's selected
precision mode, which is 80-bit extended precision. to get a correctly
rounded double precision output, we check for the only corner cases
where two-step rounding could give different results than one-step
(extended-precision mantissa ending in 0x400) and adjust the mantissa
slightly in the opposite direction of the rounding which the fpu
already did (reported in the c1 flag of the fpu status word).

this should have near-zero cost in the non-corner cases and at worst
very low cost.

note that in order for sqrt() to get used when compiling with gcc, the
broken, non-conformant builtin sqrt must be disabled.

thanks to the hard work of Szabolcs Nagy (nsz), identifying the best
(from correctness and license standpoint) implementations from freebsd
and openbsd and cleaning them up! musl should now fully support c99
float and long double math functions, and has near-complete complex
math support. tgmath should also work (fully on gcc-compatible
compilers, and mostly on any c99 compiler).

based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from
nsz's libm git repo, with some additions (dummy versions of a few
missing long double complex functions, etc.) by me.

various cleanups still need to be made, including re-adding (if
they're correct) some asm functions that were dropped.