[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120227210253.GA25004@port70.net>
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.
