From owner-svn-src-all@FreeBSD.ORG Tue Mar 13 05:14:35 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 CAFCB106566B; Tue, 13 Mar 2012 05:14:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC228FC0A; Tue, 13 Mar 2012 05:14:35 +0000 (UTC) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2D5EYLq032549; Tue, 13 Mar 2012 16:14:34 +1100 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 mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2D5EPLc022047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 16:14:26 +1100 Date: Tue, 13 Mar 2012 16:14:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Dimitry Andric In-Reply-To: <201203122107.q2CL7MYo086974@svn.freebsd.org> Message-ID: <20120313153902.Y1611@besplex.bde.org> References: <201203122107.q2CL7MYo086974@svn.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: r232894 - head/contrib/llvm/tools/clang/lib/Basic 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: Tue, 13 Mar 2012 05:14:36 -0000 On Mon, 12 Mar 2012, Dimitry Andric wrote: > Log: > Pull in r145194 from upstream clang trunk: > > Make our handling of MMX x SSE closer to what gcc does: > > * Enabling sse enables mmx. > * Disabling (-mno-mmx) mmx, doesn't disable sse (we got this right already). > * The order in not important. -msse -mno-mmx is the same as -mno-mmx -msse. > > Some configure scripts depend on this. > > PR: i386/165968 > MFC after: 3 days Can you turn off use of SSE[2] for float and double precision on i386? This use might break the ABI, and FreeBSD headers don't support it. I use the following to hack around the brokenness: % Index: math.h % =================================================================== % RCS file: /home/ncvs/src/lib/msun/src/math.h,v % retrieving revision 1.82 % diff -u -2 -r1.82 math.h % --- math.h 12 Nov 2011 19:55:48 -0000 1.82 % +++ math.h 4 Jan 2012 05:09:51 -0000 % @@ -125,4 +130,10 @@ % : __signbitl(x)) % % +#ifdef __SSE_MATH__ % +#define __float_t float % +#endif % +#ifdef __SSE2_MATH__ % +#define __double_t double % +#endif % typedef __double_t double_t; % typedef __float_t float_t; Parts of my libm make critical (at least for optimality) use of float_t and double_t, and break when clang doesn't match either gcc's behaviour or what the headers say they are. The above changes the header to match clang's behaviour. There is still an ABI problem. Although the ABI isn't strictly broken (since clang uses the normal ABI for function calls), programs and libraries should be able to assume that float_t and double_t are independent of the compiler; but with clang, they even depend on the compiler flags. Also, converting to the normal ABI across function calls is a slow operation. clang on most of libm ends up being slower on i386 with the SSE "optimization" than gcc without this optimization. clang doesn't really understand the i387 so it is even slower without this opimization. FLT_EVAL_METHOD is also quite broken (it is -1, which is only correct for clang with SSE because -1 can mean anything and what it actually means is undocumented). My libm also makes critical use of FLT_EVAL_METHOD, but I havn't tested the parts that do as much as the parts that use float_t etc., and it turns out that use of float_t etc. makes FLT_EVAL_METHOD unimportant. clang and gcc define __FLT_EVAL_METHOD__, but get it wrong in different ways, so this definition is unusuable. For example, it is always 0 for clang; this is correct with SSE, but without SSE, -1 is correct. Thus __FLT_EVAL_METHOD__ is unusable for defining FLT_EVAL_METHOD. The SSE defines work better and can be used to define FLT_EVAL_METHOD as well as float_t and double_t. You just have to know that clang has the same compiler bugs^Wfeatures as gcc, so that FLT_EVAL_METHOD must be define as -1 if the i387 is used. Note that __SSE[2]_MATH__ are quite different from __SSE[2]__. My libm also uses the latter in critical ways without problems. Bruce