-ffast-math and floating point reordering

[Geert Bosch]

On Mar 25, 2004, at 12:58, Dale Johannesen wrote:
> One point I haven't seen yet:
> A couple of strict-constructionists have asserted that people
> who want reassociation done in a nonstandard way can easily rewrite 
> their
> code to achieve this.  This is not really true, because such 
> expressions
> often arise as a result of other optimizations, in a way that isn't 
> obvious
> from the source.  Offhand, inlining, unrolling, and constant/copy 
> propagation
> can all do it, and there are probably more.
>

This is a good point, and it also serves as an illustration
of weaknesses in the "just add another command-line option" philosophy.
For example, in writing various elementary floating-point functions, it
definitely is necessary to prevent unsafe transformations in order to
attain accuracy requirements for the entire domain of the function.

On the other hand, it is also desirable in many cases to inline these
functions, especially when one of the operands is a constant. How can
we specify that this code that relies on strict semantics will not
be affected by the command-line options.

A similar issue exists the other way around. There may be library
functions where the various transformations are known to be safe,
and which may benefit from them. Think of a graphics routines for
coordinate transformations for example.

One solution seems to allow having tree-level operations for addition,
multiplications etc. that specify wether they are
   - associative
   - communicative
   - potentially trapping
   - supporting non-finite value semantics
   - supporting non-default rounding

This way front ends can set these attributes depending on language
rules and/or constructs in the source specifying certain behavior.

   -Geert