This is the mail archive of the
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? A numerical viewpoint
- To: gcc at gcc dot gnu dot org
- Subject: Re: What is acceptable for -ffast-math? A numerical viewpoint
- From: Jonathan Thornburg <jthorn at galileo dot thp dot univie dot ac dot at>
- Date: Sat, 4 Aug 2001 11:41:28 +0200
- Cc: Jonathan Thornburg <jthorn at thp dot univie dot ac dot at>
- References: <url:http://gcc.gnu.org/ml/gcc/2001-08/msg00009.html> <url:http://gcc.gnu.org/ml/gcc/2001-07/msg02141.html> <url:http://gcc.gnu.org/ml/gcc/2001-08/msg00176.html> <url:http://gcc.gnu.org/ml/gcc/2001-08/msg00192.html>
In message <url:http://gcc.gnu.org/ml/gcc/2001-08/msg00176.html>,
| [[...]] if I grant license to do this by saying
| -ffast-math, I would like very much for the compiler to (eg) convert
| (...)/5.0 into 0.2*(...). My philosophy is that if I care about
| exact bit-for-bit rounding, then I shouldn't use -ffast-math.
| Having optimization change program results is a trickier case.
| I guess I'd like this to be user-controllable. [[...]]
In message <url:http://gcc.gnu.org/ml/gcc/2001-08/msg00192.html>,
dewar <dewar at gnat dot com> pointed out
> But *all* the "optimizations" you suggest *do* change program results!
Sorry, I didn't choose my examples carefully enough.
For (binary) IEEE arithmetic, transforming (...)/2.0 into (...)*0.5
won't change program results, because 1/2 is an exactly representatable
(binary) IEEE floating point number and IEEE specifies that the result
is the true mathematical result (identical in both cases precisely because
1/2 is exactly representable) rounded to the destination format. (I think
this argument is still valid even in the presence of +/- 0, +/-infinity,
and NAN.) So, I would argue that gcc could reasonably leave this
transformation enabled by default. (We could of course also provide a
"do arithmetic exactly as I wrote it" mode which disables this.)
In contrast, my earlier example of (...)/5.0 --> (...)*0.2 *does*
change program results in the last bit or two (because 0.2 can't be exactly
represented in binary floating-point), so we might reasonably require
explict permission from the user (eg -ffast-math) before doint this.
We might also disable this transformation if the user requests "only
optimizations that don't change results".
At least in the absence of cross-compilation, it's quite practical
(with careful programming -- and _this_ programming is an example of
code that requires a "do arithmetic exactly as I wrote it" mode!) to
check at compile-time whether or not a given literal constant can be
exactly represented in a given floating-point format, and thus whether
or not the reciprocal transformation will change program results (slightly).
-- Jonathan Thornburg <email@example.com>
Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
Golm, Germany http://www.aei.mpg.de/~jthorn/home.html
"The first strike in the American Colonies was in 1776 in Philadelphia,
when [...] carpenters demanded a 72-hour week." -- Anatole Beck