Date: Tue, 31 Dec 1996 06:47:23 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, proff@iq.org Cc: rms@gnu.ai.mit.edu Subject: Re: libmsun Message-ID: <199612301947.GAA07092@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Only then did I find out that, contrary to what one would intuit, >libm is not used for /usr/lib/libm* but rather the SunPro fdlibm >from /usr/src/lib/msun (perhaps it is time to nuke the old >Berkeley one?). It has a few advantages, such as working on non-IEEE machines and separate implementations of gamma() and log(gamma()). >fdlibm does have i386/i387 support, though not as many functions >are asm/fpu coded compared to the linux libm. If I notice a difference >speed betwixt it and libmdj, then this is the obvious place for >optimisation. The sun code is certainly much more pleasant to look >at than the glib/linux/dj mess. fdlibm emphasizes accuracy over efficiency. The i387 support already breaks some of that. E.g., the i387 doesn't use a 396-digit approximation for pi, and exp(x) is implemented using the too-simple formula exp(x) = 2^(x * log2(e)). The accuracy of this formula depends on the multiplication being done in extended precision (which isn't the default in FreeBSD) and the result being interpreted as double precision. A full extended precision exp() would require at least as much code as fdlibm's C version. >Now, in terms of compile-time optimisation of fdlibm, we have: >Now, in terms of compile-time optimisation of fdlibm, we have: > >[lots of comments in makefile ] > >CFLAGS+= -D_MULTI_LIBM -D_POSIX_MODE -D_IEEE_LIBM > >Do we really need MULTI and POSIX? No. -D_MULTI_LIBM -D_POSIX_MODE -D_IEEE_LIBM is a bogus combination of flags. It is equivalent to IEEE_LIBM alone (fastest) Whoever imported the makefile apparently didn't read the comments. We really need only POSIX to get ANSI support. This would be even slower than now, and the ANSI support is slightly broken, so I didn't bother fixing this. >The linux libm has the following specific optimisations applied: > > -ffast-math -mieee-fp -mieee-fp is the default. -ffast-math is probably not a good idea in libmsun. It probably doesn't make much difference, and libmsun assumes full IEEE behaviour, right down to calculating expressions such as the following at run time to get their IEEE side effects: static const double huge = 1e300; ... return (huge * huge); /* return +Inf and set IEEE overflow flag */ gcc -O optimizes this to +Inf at compile time and doesn't set the overflow flag. My version of the library uses the hack `#define const volatile const' to avoid the optimization. This mainly slows things down some more :-]. >If the flow path in msun functions is such that NaNs/other invalid >parameters are not used, then this optimisation would be a small win. They are used. See e.g. e_pow.c where there are 19 special boundary cases involving NaNs or Infs. >However, we find that -ffast-math does more than this snippet of documentation >would have us believe. > >`-mno-fancy-math-387' > Some 387 emulators do not support the `sin', `cos' and `sqrt' > instructions for the 387. Specify this option to avoid generating > those instructions. This option is the default on FreeBSD. As of > revision 2.6.1, these instructions are not generated unless you > also use the `-ffast-math' switch. > >This is silly. The only way we can have gcc use its builtins for >sin, cos and sqrt (possibly the three most used high-level fpu >functions) is to ignore several error conditions. Clearly this >isn't acceptable as a default for user code - however we can take >precautions in libm for functions that use the gcc builtins and >activate -mfancy-math-387 and -ffast-math for its compilation. I believe that the change in 2.6.1 was because the 387 builtins are fast and wrong. They aren't ANSI conformant, and the trig functions don't do range reduction. >It is also possible the documentation is out of date. Someone >care to check this? The man page is a bit out of date, but gcc.info* is OK. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612301947.GAA07092>