Re: Compiler Correctness

Marco van de Voort <marcov@stack.nl> wrote:
>...FPU operations are also a can of worms. This e.g. due to additional
>precision in, at least x86, CPUs and the related rounding when saving
>to mem, the outcome of FPU operations is also dependant on the path.
>So result:=x*y*z is different from a1:=x*y result:=a1*z (if a1 is a memory
>location)


Not always. It *is* tricky to do floating-point constant folding, but
there are cases where it can be done, and it is possible to
automatically determine whether it's possible for a particular
expression.


Notably, if both the compiler and the target use IEEE arithmetic, and
you evaluate an expression in the compiler -- including format
conversions and roundings where appropriate -- and evaluation causes
*no* floating-point flags to be raised (not even the Inexact flag),
then it can be evaluated at compile time and moreover it is
independent of rounding mode(*). For example, folding `5.0 * 10.0' to
`50.0' is verifiably safe.


(* With one small exception that you have to watch for: for a finite
X, X-X is always zero, but whether that's +0 or -0 depends on the
rounding mode. There are only one or two situations where it makes a
visible difference. )


You may be able to go farther than that if the language spec permits,
e.g. by allowing inexact constant folding provided rounding is
correct.


Note that I said "both the *compiler* and the target", not "both the
*host* and the target". Compilers can quite reasonably use software
floating point to be sure that they match the exact behavior of the target
machine -- it's not like they do enough compile-time floating-point
arithmetic that its performance is likely to be a problem.
--
spsystems.net is temporarily off the air; | Henry Spencer
mail to henry at zoo.utoronto.ca instead. | henry@spsystems.net

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