This is the mail archive of the
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- To: dewar at gnat dot com
- Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: ebiederm at xmission dot com (Eric W. Biederman)
- Date: 03 Aug 2001 01:39:56 -0600
- Cc: gcc at gcc dot gnu dot org, vincent at qubesoft dot com
- References: <20010801130357.B804AF2B65@nile.gnat.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.
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.