This is the mail archive of the
mailing list for the GCC project.
Re: Second Draft "Unsafe fp optimizations" project description.
- To: moshier at moshier dot ne dot mediaone dot net
- Subject: Re: Second Draft "Unsafe fp optimizations" project description.
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Mon, 06 Aug 2001 22:43:06 +0200
- CC: gcc at gcc dot gnu dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <Pine.LNX.email@example.com>
Stephen L Moshier wrote:
> Although you say your purpose is to provide a "classification of
> rearrangements," much of the discussion so far reads as no more than
> assertions and rehashing of various people's parochial opinions about
> what is important or not important. I am not persuaded by any of it
> that there needs to be even one fast-math category, never mind two or
> more of them. I suspect the real reason for fast-math is to get better
> scores on some benchmark program. That may be a legitimate business
> reason, but it does not count as any sort of technical reason to be
> supported by technical analysis.
The third rewrite of this document (tomorrow) will include a paragraph
on the purpose of the web page. The reason to go for a classification
of these rearrangements is to provide people who want these
optimisations a means of reasoning about whether they are at all
prepared (as a consequence of analysing their algorithms) to actually
Of course, after we reach consensus on the classification and are ready
to implement it, documentation has to be written which explains the
reasoning behind the classification and how people could use it to
decide whether to use optimization -ffast-math-X and/or -ffast-math-Y
(hopefully we can come up with more descriptive names).
I, personally, am certainly not driven by the desire to score well on
benchmark programs. What I *do* want is to find out if I can save 10 %
elapsed time _on our code_ at the expense of a small accuracy loss. I
feel there are more people like me out there. It is for them (and to
prevent future "discussions" on this issue) that I'm going through all
> There are some technically legitimate reasons for a programmer to make
> associative law transfomations, for example in the effort to keep a
> pipeline filled or to do vectorizing. These tend to be both
> machine-specific and algorithm-specific and I think that trusting the
> compiler to be smarter than the programmer about this is not a very
> good bet.
Hmmm, I'd argue just the other way around - in fact, that's why I'm not
at all enthousiastic about doing all sorts of "allowed" transformations
in the Fortran front end - it's too far removed from the part of the
compiler that knows about pipelines and functional units.
Toon Moene - mailto:firstname.lastname@example.org - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)