>The optimization " n+1 > n ==> True " is extremely useful in array
>subscript analysis, bounds checking etc. and is correct as long as n
>terminates (is not bottom). The cases where this optimization is used
>most often, n usually terminates. A more diligent compiler would use
>the optimization only if it could prove that n does terminate. I will
>take my chances with a fast but less diligent optimizing compiler
>which in some diabolical cases produces 3 when it should not have
>terminated.
>Both the Id compiler and now the pH compiler follow this philosophy.
>May be we should let an implementation do whatever it pleases in case
>of an error. If we regard non-termination as an error then producing a
>value in case of non-termination may not seem so bizarre. However,
>there are many cases where I really do want my errors reported. I
>think such compiler/language decisions should be taken on pragmatic
>grounds.
I think it is important that these "almost always semantics-preserving"
optimizations are not carried out silently. If they are, then programmers
may start to rely on them and then their programs may break if they are
compiled with a compiler that does not perform the optimization. On the
other hand it is perfectly true that many useful optimizations have this
character. So one would like some kind of user control.
I think that sometimes the actual specification one has in mind is not as
rigid as the one that actually is implemented by the code. The problem we
had here earlier, about reordering reductions where the operations are only
"almost AC" (e.g., floating-point arithmetic), is similar. Often one
wouldn't care about the numerical variations resulting from different
reduction orders, but sometimes they could matter.
Bjorn Lisper
