Date: Mon, 2 Jan 2012 04:48:57 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Dimitry Andric <dim@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r228801 - head Message-ID: <20120102041718.T54509@besplex.bde.org> In-Reply-To: <4F008EA0.3080800@FreeBSD.org> References: <201112221503.pBMF3m0w021930@svn.freebsd.org> <20120101020442.GA94452@zim.MIT.EDU> <4F008EA0.3080800@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Jan 2012, Dimitry Andric wrote: > On 2012-01-01 03:04, David Schultz wrote: >> On Thu, Dec 22, 2011, Dimitry Andric wrote: >>> Remove -mfancy-math from LIB32CPUFLAGS for amd64. It has been default >>> for our gcc since more than three years (see r181534, which is also in >>> stable/9 and stable/8). This flag used to be for the benefit of the >>> old >>> in-kernel math emulator, which was removed more than eight years ago. >> >> Quite the opposite, actually. gcc/freebsd used to be hard-coded to >> use -mno-fancy-math-387 by default, which was really only appropriate for >> FPUless x86 chips back when FreeBSD supported them. The makefile >> setting overrides the old gcc default. The flag isn't "for the >> benefit of the in-kernel math emulator"; it's actually to reap the >> benefits of *not* having an in-kernel math emulator! >> >> Do you know if clang has the correct default here, or if it picked up >> trunk gcc's bogus default? It doesn't seem to support the flag to >> change the behavior, and it seems to default to -mno-fancy-math-387. >> (The flag should only affect things when -ffast-math is also specified.) > > As far as I can see, clang always generates calls to sin(), cos() etc. > It never inlines them to direct 387 instructions. Isn't that what we > want? Yes (never inlining is what we want, since the i387 is slow and very innacurate near all multiples of pi/2). > In any case, I don't see a quick way of getting it to emit 387 > instructions directly. It simply looks like it is not supported. The > -funsafe-math-optimizations is not recognized, and the -ffast-math > option is accepted, but ignored. -ffast-math acts strangly for gcc too: - on i386 in FreeBSD-10.0-CURRENT, it gives inline sin(). This is prevented by -mno-fancy-math-387. Apparently, -mno-fancy-math-387 is not the default. - on amd64 in FreeBSD-9.0-BETA1, it doesn't give inline sin(), even on a long double arg. However, it does give inline sinl() on a long double arg. I think this doesn't depend on the FreeBSD version. It should depend on the arch -- the i387 keeps growing relatively slower up to at least core2, and there should be some large numbers in the tables to disfavour it more (but there aren't). The tables would also need to know the speed of the library implementation to make the correct decision based on speed. The decision is accidentally correct for amd64, because the library versions are still quite slow for long doubles, but quite fast for doubles provided the arch later than Athlon64, and very fast for floats provided the arch is later than Pentium1. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120102041718.T54509>