From owner-cvs-all@FreeBSD.ORG  Thu Mar  6 03:36:55 2008
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 163F7106566B;
	Thu,  6 Mar 2008 03:36:55 +0000 (UTC) (envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101])
	by mx1.freebsd.org (Postfix) with ESMTP id 9932C8FC15;
	Thu,  6 Mar 2008 03:36:54 +0000 (UTC) (envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (localhost [127.0.0.1])
	by zim.MIT.EDU (8.14.2/8.14.2) with ESMTP id m263c7jw047430;
	Wed, 5 Mar 2008 22:38:07 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by zim.MIT.EDU (8.14.2/8.14.2/Submit) id m263c7O5047429;
	Wed, 5 Mar 2008 22:38:07 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Date: Wed, 5 Mar 2008 22:38:07 -0500
From: David Schultz <das@FreeBSD.ORG>
To: Colin Percival <cperciva@FreeBSD.ORG>
Message-ID: <20080306033807.GB47280@zim.MIT.EDU>
Mail-Followup-To: Colin Percival <cperciva@FreeBSD.ORG>,
	Bruce Evans <brde@optusnet.com.au>, Bruce Evans <bde@FreeBSD.ORG>,
	src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG,
	cvs-all@FreeBSD.ORG
References: <200803051121.m25BLE03035426@repoman.freebsd.org>
	<47CE8396.6020803@freebsd.org>
	<20080306095645.V7605@delplex.bde.org>
	<47CF5AE8.2090101@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47CF5AE8.2090101@freebsd.org>
Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG,
	Bruce Evans <bde@FreeBSD.ORG>,
	Bruce Evans <brde@optusnet.com.au>, cvs-all@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/i386/include _types.h
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2008 03:36:55 -0000

On Wed, Mar 05, 2008, Colin Percival wrote:
> Bruce Evans wrote:
> > On Wed, 5 Mar 2008, Colin Percival wrote:
> >> Bruce Evans wrote:
> >>>   Change float_t and double_t to long double on i386.
> >>
> >> Doesn't this have a rather severe performance impact on any code which
> >> uses double_t?
> > 
> > No.  As mentioned in the commit message, this has no performance effect
> > except in cases where it avoids compiler bugs.  [...] if you use long double
> > for memory variables then you get a severe performance impact and some
> > space loss for the load instruction, since loading long doubles is
> > much slower than loading doubles (about 4 times slower on Athlons).
> 
> Either I'm misunderstanding something, or you seem to be disagreeing with
> yourself here... if I have the following code
> 
> double_t foo, bar, foobar;
> foobar = foo + bar;
> 
> then prior to this change the processor loads and stores doubles, while
> after this change the processor loads and stores long doubles, with the
> associated performance penalty.

If gcc actually implemented IEEE 754R / C99 / LIA1 correctly, then
when compiling something like 'double x = y' would require it to
store the value to memory and then reload it to force it to 53-bit
precision. The whole point of double_t is to allow the programmer
to ask for a variable that is "at least double precision", so that
the compiler isn't forced to clip everything to double precision
if it's inefficient to do so. However, gcc doesn't compile the above
expression correctly, and FreeBSD works around the problem by
setting the default rounding mode to 53 bits, which is why it's
pointless to increase the size of double_t.