amd64/115581: [fix] -mfancy-math-387 has no effect

[Bruce Evans]

On Thu, 16 Aug 2007, Simun Mikecin wrote:

>> Description:
> 32-bit compatibility libraries on FreeBSD/amd64 are compiled using -mfancy-math-387 gcc option. As stated in gcc(1):
>
>       -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, OpenBSD
>           and NetBSD.  This option is overridden when -march indicates that
>           the target cpu will always have an FPU and so the instruction will
>           not need emulation.  As of revision 2.6.1, these instructions are
>           not generated unless you also use the -funsafe-math-optimizations
>           switch.
>
> So, using just -mfancy-math-387 has no effect. It should be used in combination with -funsafe-math-optimizations or it should not be used.

It should not be used, especially on amd64 systems since basic FP
instructions are relatively fast compared with the fancy instructions
(except for sqrt).  The 64-bit amd64 libm intentionally never uses the
fancy instructions (except for sqrt), partly because they are not much
faster and partly because they are much less accurate.  The fancy
instructions are not used for float precision (unless you pessimize
things using -mfancy-math-387) since they are about 3 times slower
than the library versions on small args.

Is -mno-fancy-math-387 still actually the default on FreeBSD (with FreeBSD's
config/i386/freebsd.h which is quite different (mostly gratuitously different)
from the distribution one)?  FreeBSD hasn't supported the math emulator for
about 10 years.

> --- Makefile.inc1.orig	Tue Jul 10 18:39:36 2007
> +++ Makefile.inc1	Thu Aug 16 18:30:44 2007
> @@ -238,7 +238,7 @@
> .else
> LIB32CPUTYPE=	${TARGET_CPUTYPE}
> .endif
> -LIB32FLAGS=	-m32 -march=${LIB32CPUTYPE} -mfancy-math-387 -DCOMPAT_32BIT \
> +LIB32FLAGS=	-m32 -march=${LIB32CPUTYPE} -mfancy-math-387 -funsafe-math-optimizations -DCOMPAT_32BIT \
> 		-iprefix ${LIB32TMP}/usr/ \
> 		-L${LIB32TMP}/usr/lib32 \
> 		-B${LIB32TMP}/usr/lib32

-unsafe-math-optimizations should be named
-broken-floating-point-optimizations and should almost never be used.  It
should never be used for compiling FreeBSD's math library, since the library
depends on floating point not being very broken.

gcc-4.2 still says the above, but doesn't actually do the above for
sqrt.  It inlines sqrt (but not cos or sin) without
-funsafe-math-optimizations.  I think the difference is just due to
inlining sqrt not actually being unsafe and the documentation of
-ffancy-math-387 being many years out of date (this difference is not
new).  Inlining cos and sin would be safe if the inline code were large
enough to detect the unsafe cases, but the inline code only checks for
the result being a NaN (?), which is more than enough for sqrt but not
enough for cos or sin.

gcc (at least in 4.2) has a -fno-math-errno option which defaults to the
wrong thing for FreeBSD (-fmath-errno) but the correct think on Darwin.
-funsafe-math-optimizations apparently has the apparently-undocumented
effect of turning off on -fno-math-errno.  So -march=pentium4 gives the
following inlining of the fancy functions:

Default:
 	sqrt: inlined, bogus errno handing
 	cos, sin: not inlined
with -fno-math-errno:
 	sqrt: inlined, optimal
 	cos, sin: not inlined
with -funsafe-math-optimizations:
 	sqrt: inlined, optimal
 	cos, sin: inlined, broken (additional breakage only for large args)
 	cosf: inlined, optimal
 	cosf, sinf: inlined, broken (for large args, and small args near a
 		    multiple of pi/2), pessimized (only for small args)

Bruce