This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? A numerical viewpoint
- To: gcc at gcc dot gnu dot org, ross dot s at ihug dot co dot nz
- Subject: Re: What is acceptable for -ffast-math? A numerical viewpoint
- From: dewar at gnat dot com
- Date: Mon, 6 Aug 2001 05:23:13 -0400 (EDT)
<<Can we please take it as given that no transformation will be applied
without something at least vaguely resembling a rational argument that
it could be an actual optimisation?
>>
Once you allow a compiler to make transformation X, then the interaction
of transformations is often such that the idea of "rational argument" is
highly dubious. I already gave an argument showing why it is perfectly
believeable that a compiler would transform
a / b
into
(a*K) / (b*K)
Sure, it is a somewhat unlikely combination of circumstances, but if there
is one thing that anyone who has worked on optimizing compilers knows, it is
that unlikely combinations of things do happen in ways that are often very
hard to anticipate, and optimzers are not in the business of "well this
speeds up most programs, and miscompiles others, but we can't tell you
the difference".
So I am afraid that we can't take that as a given, ...
Your position seems to be that a knowledgable programmer should right the
program in a manner such that it has guaranteed correct semantics regardless
of whether the floating-point model is real arithmetic or IEEE arithmetic,
or some mixture. That's extremely difficult to do. You might want to review
some of the arguments over the Brown model of floating-point as used in
Ada 83. This model does in fact go part of the way to this position (though
it comes nowhere near allowing arbitrary transformations), and even with this
much more limited view (for one thing it allows arbitrary extra precision
all the time), a number of numerical analysts have argued that it makes it
impossible to analyze programs properly from an error limit propagation
point of view.