The other view point here is "please don't assume the programmer
is incompetent and does not know what he is doing. Floating-point
operations are precisely defined in IEEE and if I am a serious
fpt programmer, I write the computations I want, and I do not
want the compiler substituting arbitrary non-equivalent
expressions.
It's OK by me (though I consider it dubious and useless) to have
such optimizations around. It is absolutely essential that it be
possible to disable them.
I suppose that for people writing casual fpt code without error
analysis assuming that it gives some acceptable approximation
of real arithmetic, such optimizations are relatively harmless.
After all if you are happy with wrong results, then I suppose
getting different wrong results faster is not unacceptable.
(wrong results here = results whose accuracy is unknown).
But as above, for serious fpt programming, a compiler that
performs non-meaning preserving transformations (e.g. assuming
that fpt addition is commutative, or even worse associative),
is a menace.