Re: Floating point constant question

bill@amber.csd.harris.com (Bill Leonard)
Tue, 29 Mar 1994 21:09:06 GMT

          From comp.compilers

Related articles
Floating point constant question mahlke@crhc.uiuc.edu (Scott Mahlke) (1994-03-28)
Re: Floating point constant question joe@sanskrit.ho.att.com (1994-03-29)
Re: Floating point constant question chase@Think.COM (1994-03-29)
Re: Floating point constant question bill@amber.csd.harris.com (1994-03-29)
Re: Floating point constant question maydan@mti.mti.sgi.com (1994-03-29)
Re: Floating point constant question hbaker@netcom.com (1994-03-30)
Re: Floating point constant question conte@ece.scarolina.edu (1994-03-30)
Re: Floating point constant question chase@Think.COM (1994-03-30)
Re: Floating point constant question hbaker@netcom.com (1994-03-31)
Re: Floating point constant question przemek@rrdjazz.nist.gov (1994-03-31)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.csd.harris.com (Bill Leonard)
Keywords: arithmetic, optimize
Organization: Harris CSD, Ft. Lauderdale, FL
References: 94-03-157 94-03-176
Date: Tue, 29 Mar 1994 21:09:06 GMT

chase@Think.COM (David Chase) writes:
> I don't know of any compilers that do, and if they did them generally
> (i.e., if they'd do exactly what you did) then I wouldn't buy them.


We do this optimization under certain circumstances, and it is further
controlled by a separate compiler option.


> If your goal is to not change the I/O behavior of a legal program
> (something I always take for granted as a constraint on an optimizer),


There are lots of legal optimizations that can affect the numerical answer
of a legal program. For a simple one, consider evaluating (a + b + c).
In the absence of parentheses around the two additions, the compiler is
allowed to evaluate this as ((a + b) + c), as (a + (b + c)), or even as
((a + c) + b).


Just because it's a legal program does *not* mean it is guaranteed to give
the exact same answer on every implementation, or even on the same
implementation from one day to the next.


> then my rule is that you cannot do this if the reciprocal cannot be
> represented exactly, in fact not even if the divisor cannot be represented
> exactly (the results might be more accurate, but different, and without
> knowing more about the intent of the programmer, different could be as bad
> as plain old wrong).


That's probably a reasonable rule for this case, since the programmer has
no language-defined way to disable the optimization. Alternatively,
though, you can give the user control via compiler options and let him
pick and choose. You might, for instance, provide a "damn the torpedoes,
full speed ahead" option that enables every known optimization.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--


Post a followup to this message

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