[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Mar 2012 16:17:11 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libm
* Rich Felker <dalias@...ifal.cx> [2012-03-05 09:04:59 -0500]:
> On Mon, Mar 05, 2012 at 09:51:35AM +0100, Szabolcs Nagy wrote:
> Hm? If you need a macro to test whether an argument is an integer or
> floating point, try this:
>
> #define __IS_FP(x) !!((1?1:(x))/2)
>
oh nice
(and subtle)
> I can do it, but might be another day or two. Feel free to keep fixing
> stuff up in the mean time if you have time. :)
>
ok
> > i saw that you removed the compound literal definition of
> > NAN, INFINITY etc from math.h
> >
>
> The removal has nothing to do with c89; it's actually the fact that
> the compound literal definition was not a constant expression and the
> standard requires these macros to expand to constant expressions.
>
i see
> adopted it. In any case I see no good way to define them without
> compound literals except the function calls..
>
btw while testing these macros i noticed that when
multiple classification macros are used fpclassify
gets called many times
(with the previous solution)
the extra calls could be optimized by adding
__attribute__((const)) to fpclassify
(resulted less calls, smaller code size etc)
> > hm but float compare will compile to different instruction
> > so there is at least performance difference
>
> Yes. In principle it would be faster to do everything as floating
> point so no store/load delays are needed. In relality I doubt it makes
> much of a difference. In almost all of these functions the actual
> computation time dominates.
>
i see
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.
