This is the mail archive of the
mailing list for the GCC project.
Re: Draft "Unsafe fp optimizations" project description.
- To: dewar at gnat dot com, toon at moene dot indiv dot nluug dot nl, tprince at computer dot org
- Subject: Re: Draft "Unsafe fp optimizations" project description.
- From: dewar at gnat dot com
- Date: Sun, 5 Aug 2001 11:51:46 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, lucier at math dot purdue dot edu
<<set by Fortran. As Toon mentioned, placing too many
additional transformations under -ffast-math without options
to shut them off may prevent the use of -ffast-math in
situations where it is useful now. I face this problem daily
with commercial compilers, more so with C++, where the choices
are between very little optimization with insufficient
performance, and a broken application.
First a question: Just how useful *is* -ffast-match "now", does anyone have
measurements to contribute. And if there are programs where it helps
significantly, are there any analyses of why and how.
Second, I agree it is fine to have finegrained control, but in practice most
people will only know the default and perhaps -ffast-math and not much more,
so it is indeed important to tune the default to be maximally useful. That
indeed is the *entire* discussion here.
Obviously no one objects to a specific
switch that specifically does a/b/c => a/(b*c)
Well I guess they might think it was useless and therefore silly if not
validated as useful in speeding up programs, but there would be no danger
of accidental surprise, so specific options of this type are never risky,
since the assumption of the risk is very transparent.