From mboxrd@z Thu Jan  1 00:00:00 1970
From: ebiederm@xmission.com (Eric W. Biederman)
To: dewar@gnat.com
Cc: gcc@gcc.gnu.org, vincent@qubesoft.com
Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
Date: Fri, 03 Aug 2001 00:46:00 -0000
Message-id: <m1hevpy4kz.fsf@frodo.biederman.org>
References: <20010801130357.B804AF2B65@nile.gnat.com>
X-SW-Source: 2001-08/msg00160.html

dewar@gnat.com writes:

> <<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.

For reasonable limits I suggest that we look at the accuracy lost with
the traditional tools.  And say if an optimization or set of
optimizations result into too much lost accuracy the are unacceptable.

In particular there is a large body of literature that delves into
calculating exactly how much error any given floating point
operation introduces into a calculation.  That is why -mieee is useful
for some poeople.  

So since we can calculate the additional error term introduced by a
given optimization or set of optimizations we should use that when
deciding if that code change is allowable.  Then we only have to 
see if it the code change is actually an  optimization.

Eric