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.