Using float_t and double_t in math functions

[Rich Felker <dalias@aerifal.cx>]

Hi all,

Today I've been doing some experimenting on the relative math
performance of musl and glibc. After eliminating a lot of bogus
results (the gcc 4.4 on my test machine (x86) was causing musl's
configure to use -ffloat-store, which kills performance) things mostly
look good. Aside from sqrt (which is more costly on musl because
glibc's violates the requirement of correct rounding), everything I'm
testing seems faster, in some cases up to five times faster.

While debugging the slowdown from -ffloat-store, one thing I ran
across is that a lot of functions end up performing store/load pairs
to drop excess precision when storing intermediate results. The
situation is much worse with -ffloat-store, but persists with modern
gcc because of -fexcess-precision=standard, which is implied anyway by
-std=c99.

As far as I can tell, in most of the affected code, keeping excess
precision does not hurt the accuracy of the result, and it might even
improve the results. Thus, nsz and I discussed (on IRC) the
possibility of changing intermediate variables in functions that can
accept excess precision from float and double to float_t and double_t.
This would not affect the generated code at all on machines without
excess precision, but on x86 (without SSE) it eliminates all the
costly store/load pairs. As an example (on my test machine), it
dropped the cost of sinf(0.25) from 180 cycles to 130 cycles (glibc
takes 140 cycles, the main difference apparently being that glibc's
math library updates errno).

Unless there are objections, I think we should change float and double
intermediate variables in the implementations of math functions to
float_t and double_t, except where it's actually important to avoid
excess precision. Comments?

Rich