From owner-svn-src-all@FreeBSD.ORG Sun Jan 1 17:49:02 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 563BD106567C; Sun, 1 Jan 2012 17:49:02 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id E27378FC1B; Sun, 1 Jan 2012 17:49:01 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q01Hmv03010424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 04:48:59 +1100 Date: Mon, 2 Jan 2012 04:48:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric In-Reply-To: <4F008EA0.3080800@FreeBSD.org> Message-ID: <20120102041718.T54509@besplex.bde.org> References: <201112221503.pBMF3m0w021930@svn.freebsd.org> <20120101020442.GA94452@zim.MIT.EDU> <4F008EA0.3080800@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r228801 - head X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 17:49:02 -0000 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