Date: Mon, 27 Feb 2012 22:02:53 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: libm * Rich Felker <dalias@...ifal.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?
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.