Re: inlining + optimization = nuisance bugs

christian.bau@isltd.insignia.com (Christian Bau)
22 Sep 1998 14:38:50 -0400

          From comp.compilers

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]
| List of all articles for this month |

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);
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.