From owner-cvs-all@FreeBSD.ORG Thu Mar 6 03:15:40 2008 Return-Path: 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 BF588106566C; Thu, 6 Mar 2008 03:15:40 +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 5A8A78FC27; Thu, 6 Mar 2008 03:15:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m25NUIpZ001927; Thu, 6 Mar 2008 10:30:18 +1100 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m25NUEND016872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 10:30:15 +1100 Date: Thu, 6 Mar 2008 10:30:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Colin Percival In-Reply-To: <47CE8396.6020803@freebsd.org> Message-ID: <20080306095645.V7605@delplex.bde.org> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <47CE8396.6020803@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 03:15:41 -0000 On Wed, 5 Mar 2008, Colin Percival wrote: > Bruce Evans wrote: >> Modified files: >> sys/i386/include _types.h >> Log: >> 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. In fact, I need it partly to improve performance in cases where other methods of avoiding the compiler bugs (including fixing the compiler) have a severe performance effect. Using a correctly defined double_t makes it possible for non-broken generated code to operate entirely on registers, while using plain double requires either broken generated code or lots of conversions via memory. E.g.: double x, y, z; z = x + y; Typical wrong generated i386 code for this: fadd %st(1),%st Non-broken code for this (get it by fixing the compiler or messing up the source code using something like STRICT_ASSIGN()): fadd %st(1),%st fstpl mem # or fstps/flds to convert to float fldl mem Using double_t == long double: double_t x, y, z; z = x + y; Typical generated i386 code for this: fadd %st(1),%st x and y would probably start out as doubles and be loaded into registers using fldl. This gives a long double whether you want it to or not (all FP registers are long double). Then the severe performance impact is from converting the long double back to "double z" on assignment as is required for C compilers. OTOH, 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). Bruce