This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Second Draft "Unsafe fp optimizations" project description.

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

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

> 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 - - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77:
Join GNU Fortran 95: (under construction)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]