Related articles |
---|
Optimizing IEEE Floating-Point Operations daryl@hpclopt.cup.hp.com (1991-06-06) |
Re: Optimizing IEEE Floating-Point Operations bron@sgi.com (1991-06-11) |
Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14) |
Optimizing IEEE Floating-Point Operations eggert@twinsun.com (1991-06-14) |
Optimizing IEEE Floating-Point Operations cfarnum@valhalla.cs.wright.edu (1991-06-17) |
Re: Optimizing IEEE Floating-Point Operations henry@zoo.toronto.edu (1991-06-17) |
Re: Optimizing IEEE Floating-Point Operations bill@hcx2.ssd.csd.harris.com (1991-06-18) |
Re: Optimizing IEEE Floating-Point Operations jbc@hpcupt3.cup.hp.com (1991-06-19) |
Newsgroups: | comp.compilers |
From: | bron@sgi.com (Bron Campbell Nelson) |
Keywords: | arithmetic, design, Fortran, C |
Organization: | Compilers Central |
References: | 91-06-005 |
Date: | Tue, 11 Jun 91 12:02:48 -0700 |
Daryl Odnert (daryl@hpclopt.cup.hp.com) writes:
> x = 0.0; /* statement A */
> y = y * x; /* statement B */
> Let us assume that x and y are floating-point variables and that the
> underlying machine uses the IEEE floating-point representation. Assuming
> that we can determine that x does not change between A and B, should the
> expression (y * x) in statement B be replaced with 0.0? What if y is a NaN?
My own *personal* opinion is that this is a legal transformation if and
only if the runtime system traps (and aborts) on generation of NaN's and
Inf's. For example, the Fortran standard clearly states that an expression
may be replaced by one that is "mathematically equivalent" but without
specifing just what kind of "mathematics." If your particular mathematical
model includes NaN's and Inf's (e.g. the IEEE model), then this transformation
is NOT strictly legal, since the expressions are not always equivalent.
On the other hand, if your mathematical model does not have things like
NaN's and Inf's (i.e. the program blows up if such numbers are produced)
then the transformation IS legal.
Probably the "right" thing to do is to add yet another compiler option
and support both the "strict IEEE" and "intuitive" models. Just my $0.02
--
Bron Campbell Nelson
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mtn. View, CA 94039
bron@sgi.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.