Re: libm

[Szabolcs Nagy <nsz@port70.net>]

* Rich Felker <dalias@aerifal.cx> [2012-01-23 12:07:15 -0500]:
> On Mon, Jan 23, 2012 at 05:41:52PM +0100, Szabolcs Nagy wrote:
> > i've looked into libm implementations
> > to figure out what's best for musl
> 
> > the extended precision algorithms are reused across
...
> 
> Any ideas how the different ones evolved (separately written or common
> ancestor code, etc.) and where we should look to pull code from?
> 

meanwhile i looked more into libm design issues

here are some questions i come up with:
for background issues see
http://nsz.repo.hu/libm

Code organization:
(ldX is X bit long double)

Do we want ld128?
Should we try to use common code for ld80 and ld128?
How to do ld64: wrap double functions or alias them?
How to tie the ld* code to the arch in the build system?
Make complex optional?
Keep complex in math/ or cmath/?

Workarounds:

Use STDC pragmas (eventhough gcc does not support them)?
Use volatile consistently to avoid evaluation precision and const folding issues?
Use special compiler flags against unwanted optimization (-frounding-math, -ffloat-store)?
Do inline/macro optimization for small functions? (isnan, isinf, signbit, creal, cimag,..)
In complex code prefer creal(), cimag() or a union to (un)pack re,im?

Code cleanups:

Keep diffability with freebsd/openbsd code or reformat the code for clarity?
Keep e_, s_, k_ fdlibm source file name prefixes?
Should 0x1p0 float format be preferred over decimal format?
Should isnan, signbit,.. be preferred over inplace bithacks?
Is unpacking a double into 2 int32_t ok (signed int representation)?
Is unpacking the mantissa of ld80 into an int64_t ok?