Re: Floating point constant question

Scott Mahlke <mahlke@crhc.uiuc.edu> writes:
|> I have a question regarding the following compiler optimization:


|> x = y / 500.0; ===> x = y * 0.002;
|> ...
|> Is this or similar optimizations dealing with FP constants ever legal? Do
|> any compilers out there do optimizations such as this? Thanks.


|> [In Fortran it's legal, although perhaps not a good idea.]


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. 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), 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).


For an example of what can happen with an inexact divisor,
consider this program:
===============================================
double prod(double x, double y) {
    return x * y;
}
double quot(double x, double y) {
    return x / y;
}


main() {


    double w, x, y;
    int i;


    for (i = 1; i < 10000000; i++) {
        w = 1.0 + 1.0/i;
        x = quot(w,0.2);
        y = prod(w,5);
        if (x != y) {
            printf("w = %20.15f, x = %20.15f, y = %20.15f\n", w, x, y);
            break;
        }
    }
}
===============================================


When run (Sparc, Sunpro acc or Gnu gcc), it produces (roughly):


w = 1.200000000000000, x = 5.999999999999999, y = 6.000000000000000


y, the optimized answer, is mathematically correct, but it isn't the
result of the division that the programmer wrote.


Mathematical purists and speed freaks probably say "do the optimization"
whereas anyone who has ever had to debug a faulty numerical code probably
says "don't you dare". These days, given the relative costs of fast
hardware and skilled people able to debug such programs, I'd say, "don't
you dare". I can see where people writing preprocessor macros in C would
have trouble with this decision, but I think that's one of the LCD
compromises you have to make when programming in a popular language (a
compiler COULD be augmented with the types __fast_float and __fast_double,
but that would be REALLY SLEAZY, not that I'd be at all surprised if I saw
"-Dfloat=__fast_float" on some list of compiler flags for SPEC).


David Chase, speaking for myself
Thinking Machines Corp.
--

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