Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[dewar at gnat dot com]

Another issue here is that the optimizations in question are unlikely to
be that significant in practice. In real programs where performance is an
issue, there will be relatively few opportunities for this kind of
optimization, and assuming that the program was reasonably competently
written, those few cases are likely to be just those that should not
be molested.

Consdier again the assoicative case. The expression

a*b + a*c

Now there are three cases

1. The really competent programmer, who knows that the associat9ive 
transformation will blow up the error analysis, and wrote it that way
for a good reason.

2. The somewhat competent programmer, who knows nothing about fpt details,
but who wants their program to run fast. Such a programmer is likely to
rewrite this manually as

  a +(b*c)

anyway, because that's obviously "faster".

3. The incompetent programmer who knows nothing about fpt details, wants
their program to run fast, would be perfectly happy to have that
transformation done, but does not do it themselves.

These optimizations are aimed only at class 3 programmers. I think that

a) there are fewer such programmers than people think, certainly nothing
like Linus' 99%

b) even for them, it will be rare for these kind of improper optimizations
to make a difference (that's why Fortran compilers don't really mess around
that much, even though the standard allows them to).

Floating-point is always tricky. If you see

a*a*a*a

in a program, it may seem very tempting to "optimize" this
as 

T := a*a;
T*T

but even though the latter has only two operations instead of three, it
has significantly worse error bounds.