Related articles |
---|
[13 earlier articles] |
Re: inlining + optimization = nuisance bugs bear@sonic.net (Ray Dillinger) (1998-08-22) |
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-18) |
Re: inlining + optimization = nuisance bugs cfc@world.std.com (Chris F Clark) (1998-09-19) |
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-22) |
Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-09-22) |
Re: inlining + optimization = nuisance bugs chase@world.std.com (David Chase) (1998-09-22) |
Re: inlining + optimization = nuisance bugs christian.bau@isltd.insignia.com (1998-09-22) |
Re: inlining + optimization = nuisance bugs andrewf@slhosiery.com.au (Andrew Fry) (1998-09-24) |
Re: inlining + optimization = nuisance bugs comments@cygnus-software.com (Bruce Dawson) (1998-09-24) |
Re: inlining + optimization = nuisance bugs Martin.Ward@SMLtd.Com (1998-09-26) |
Re: inlining + optimization = nuisance bugs toon@moene.indiv.nluug.nl (Toon Moene) (1998-09-29) |
Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-09-29) |
Re: inlining + optimization = nuisance bugs ralph@inputplus.demon.co.uk (Ralph Corderoy) (1998-09-29) |
[8 later articles] |
From: | christian.bau@isltd.insignia.com (Christian Bau) |
Newsgroups: | comp.compilers |
Date: | 22 Sep 1998 14:38:50 -0400 |
Organization: | Insignia Solutions |
References: | 98-09-093 |
Keywords: | arithmetic |
Luddy Harrison <luddy@concmp.com> wrote:
> My reading of the programming manual for the PowerPC is that the
> internal registers that hold the intermediate result for a
> multiply-add instruction have extended precision. If this is true,
> and if it is true that occasional use of extended precision is
> 'wrong', then there is virtually no circumstance under which a
> compiler can correctly generate the PowerPC fmadd and fmsub
> instructions, for example. This strikes me as a very severe
> interpretation of floating point semantics.
You can either see it as "infinite precision intermediate result" or,
which I think is more useful, see the fmadd operation as another
"basic" operation, so you have the "basic" operations a+-b, a*b, a/b
and a*b+-c.
In case of the PowerPC, the instruction is definitely useful. It is
faster than two separate instructions, and the result is guaranteed to
be as close or closer to the mathematical result as two separate
instructions. Being faster is always good; the different result
doesnt matter in 90% of the cases, and it is an advantage in 9% of all
cases, leaving 1 percent where it is bad :-(
As an example where it is bad, normally if a*b is mathematically
greater than or equal to c*d, then a*b - c*d >= 0. This is not the
case with fmadd.
In the forthcoming C9X standard for the C language, and in existing
compilers for the PowerPC, the programmer can tell the compiler
whether it is allowed to use these instructions or not. I think in C9X
the syntax is
#pragma fp_contract on/off
or something similar, which would allow the compiler to use other
basic operations than +,-,*,/. I am not sure how far this is allowed,
that is whether it is only allowed where *+ is directly visible in an
expression, like a*b + c, or if it also is allowed if this is not
directly visible, like
double square (double x) { return x * x; }
z = square (a) + b;
double sum (double x, double y) { return x + y; }
z = sum (3.0 * a, b);
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.