Infinite optimization

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

    Date: 26 Sep 1985 0859-PDT
    From: Rem@IMSSS

    I like your idea. If an optimizing compiler happens to discover that the
    code it's trying to optimize absolutely cannot ever return nor produce any
    output, it would be nice for the LUSER if the compiler would inform the
    LUSER of that fact instead of blindly compiling a hung CPU and blindly leading
    the LUSER into executing it and having to reboot the system to escape it.
    Of course if the compiler doesn't happen to discover it, caveat emptor.

    Note such a very-smart compiler would wreak havoc with some timing benchmarks
    that do nothing useful over and over and throw away all the results; a good
    compiler could totally optimize-away such moot calculations, making the
    LISP system seem a million times faster than microcode when in fact it
    is simply punting the moot calculations. I have long advocated benchmarks
    being careful to do truly non-moot calculations. The CRAY-2 test whereby
    a large Mersenne prime is verified is a good benchmark. There's no way
    an optimizing compiler can turn the benchmark into a punt-cheat, providin
    it's a new Mersenne prime nobody computed before and hence couldn't be
    included as a special-case optimization a priori. (Did you see/hear the
    news story about that CRAY-2 test earlier this week?)
    -------

A few years ago a vendor did advertise a set of FORTRAN benchmarks
comparing their machine to a VAX.  Most of the numbers were reasonable,
but on one benchmark Brand X was several orders of magnitude faster than
the VAX.  This appeared in the table without comment.  The fact was that
their compiler had noticed that the results of the inner loops were
unused, and optimized away an entire timing subroutine.
--Guy