[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120304145041.GB5728@port70.net>
Date: Sun, 4 Mar 2012 15:50:41 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libm
* Rich Felker <dalias@...ifal.cx> [2012-03-04 01:53:40 -0500]:
> On Sat, Mar 03, 2012 at 11:57:58PM +0100, Szabolcs Nagy wrote:
> > see
> > http://nsz.repo.hu/libm
>
> Some initial questions...
>
> - Why are there two versions (one "slow") of rem_pio2?
>
originally code they are __ieee754_rem_pio2 and __kernel_rem_pio2
maybe slow is not the best name
the slow version is only called (by the non-slow one)
for large numbers (>2^20) when multi precision arithmetic
is needed using many bits of 2/pi
(there is a large ipio2 array in that file)
maybe it should be called __rem_pio2_large ?
> - Is __invtrigl.c used? It clashes with the app-reserved namespace.
>
fixed
it is used by long double inv trig functions
> gcc-specific hacks involving __typeof__. If gcc4 allows _Generic even
> with -std=c99 etc. then I think _Generic is the best.
>
no, gcc does not support it
(i have a gcc 4.7 built from svn in october and it has -std=c1x,
but _Generic is not supported)
i wrote it using generic since i couldnt come up with
any way to solve it in c99
> > how to do the long double ifdefs?
>
> #if LDBL_MANT_DIG == ...
>
ok will do that
> > check x87 fpu precision setting from ld80 code?
> > (or we assume it's extended precision)
>
> All existing code (well, mainly macro definitions) in musl assumes its
> set to extended, and we provide no code to change it.
>
ok
> > preferred way of handling consts?
> > (freebsd code uses 1.0f, (float)1, 0x1p0, static const float one=1;..)
> > (i'm not sure why 'one' or 'zero' is used instead of 1 or 0
> > maybe it's another compiler float-store bug workaround)
> > i assume (float)1.0 is the same as 1f
>
> I like 1.0f, etc. BTW are you sure 1f is valid C? Certainly 1L is not
> a valid alternative for 1.0L when you want long double..
>
ok
(1f might be wrong, i just wrote that in the mail)
> > i wonder if it's ok to use a polyeval(coeffs, x) function instead
> > of writing out the polynomial (some openbsd long double code uses
> > such thing but not everywhere)
>
> I suspect the functions that aren't using it right now depend on a
> particular evaluation order to avoid loss of precision. I could be
> wrong though; that's just my best guess.
>
it's just a minor detail, but this was one of the parts where
things could be a bit nicer and more consistent (probably)
(coeffs in array, and using some static inline eval etc,
it might not be a good idea for some technical reason,
but i dont yet see why)
> > todo:
> > - move the code to musl tree so the changes are recorded there
>
> Very interested in doing this sooner rather than later.
>
ok
complex is missing but it is not hard to add
(if you want to wait for it)
the parts i wrote may need some review or testing
(it can be done after merging of course)
(it would be nice if musl had a dedicated testing
package where one could add test functions
and easy to run)
> > - fix int32_t issues (there are many)
> > - define isnan, signbit, etc macros to be efficient and
> > change bithacks into isnan etc in the code when appropriate
>
> Try something like:
>
> union __float_rep { float __x; uint32_t __r; };
> #define __FLOAT_REP(x) ((union __float_rep){x}.__r)
>
> #define isnan(x) \
> sizeof(x)==sizeof(float) ? (__FLOAT_REP(x)&0x7fffffff)>0x7f800000 : \
> sizeof(x)==sizeof(double) ? (__DOUBLE_REP(x)&....
>
> Does that work? Of course it would work to just let it get converted
> up implicitly to long double and just have one case, but that would be
> more expensive I think.
>
ok so using compound literal
i was thinking about this
something like this will work
the difficult part is figuring out if it can be used internally
(many math functions start by turning the float/double
into unsigned int, then doing various checks to handle
special cases like nan, inf, signbit, etc using bithacks
i thought most of them could be isnan() etc
eg compare the current fmax to the freebsd one
i'm not sure if this can be done in general
because some bit hacks will be needed anyway
and it might be better doing the conversion
once
many functions do checks like
if(x < 12.34) ... else if(x < 78.9) ...
but using unsigned int arithmetics like
if ((x&bitmask) < 0xabcdef) ...
which is not clear, but i guess this
cannot be changed because float compare
does a different thing
but it would be nice to reduce the bithacks
without changing the semantics or performance)
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.
