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

[dewar at gnat dot com]

<<As long as the differences and gotchas between these two
modes is well documented, I see little reason to dismiss
-ffast-math on the grounds that it is less than perfect
compared to the default behavior.
>>

No one is dismissing -ffast-math on any grounds, we are just discussing what
it should allow. Clearly everyone has a limit on what is reasonable, we need
to discuss to get a common agreement on reasonable limits. What we are talking
about here is just how tolerant we want to be. For example, can one tolerate
computing ** using log and exp? The result can be hundreds of ULP wrong, but
perhaps this is still tolerable IF it really saves time.

The point I keep plugging is that there is no point in providing less
accurate results unless you get some significant gain from the transformation.
For example, providing true -mieee results is really expensive on the Alpha,
so it is well worth compromising. Similarly, providing exact Java semantics
on the x86 is very expensive so it is worth compromising. 

Whether the specific transformation

 a/b/c => a/(b*c)

is worthwhile is unproven. In practice divisions are far less frequent than
multiplications and additions in any case, and the number of cases where
an expression with two divisions is written in the form a/b/c is small.
Furthermore, one would expect that since programmers obviously know that
division is in general slow, they would tend to rewrite as a/(b*c) anyway,
so perhaps it is in fact quite likely that many of the cases in which
a/b/c is written are deliberate.

Yes, Linus points to a case in which due to pipeline overlap the division
is faster, but compiler writers and systems programmers are always good
at finding theoretical cases. For me, the only justification for the
transformation above is if tests show that real programs noticably benefit.
This is a fairly stiff burden.

When I was actively working on SPITBOL, I solicited optimization suggestions
for SNOBOL-4 for the SPITBOL newsletter. I got many submissions. Then I put
into place a rule that said that you must be able to show one program that
speeds up by at least 5% (people were allowed to construct a program for the
purposes). The number of suggestions dropped to close to zero :-)