Re: What is acceptable for -ffast-math? (Was: associative law in combine)

["Tim Prince" <tprince at computer dot org>]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Jan Hubicka" <jh@suse.cz>; "Toon Moene"
<toon@moene.indiv.nluug.nl>; "Joern Rennecke" <amylaar@redhat.com>;
<gcc@gcc.gnu.org>
Sent: Sunday, July 29, 2001 6:31 AM
Subject: Re: What is acceptable for -ffast-math? (Was: associative law
in combine)


> >
> > This optimization is specifically permitted for appropriate data
types
> > by the Fortran standard, with the reservation that parentheses
employed
> > to prevent re-association must be observed.  As gcc is unable to
> > distinguish between the expressions (a/b)/c and a/b/c, this
optimization
> > would violate the standard in the former case, so is undesirable for
> > enabling under -ffast-math.
> Our documentation of -ffast-math seems to be wondefully incomplette:
>
> This option causes the preprocessor macro @code{__FAST_MATH__} to be
defined.
>
> This option should never be turned on by any @option{-O} option since
> it can result in incorrect output for programs which depend on
> an exact implementation of IEEE or ISO rules/specifications for
> math functions.
>
> But my understanding is, that -ffast-math allow compiler to do
transformations
> not strictly correct, but working in was majority of cases.  The
> transofrmations mentioned above looks like good example of these.
>
> I would like to keep them under -ffast-math for simple purpose, that
users
> tends to know about -ffast-math and use it, but don't know about
possibly new
> functions.  I believe that the typical usage of Joe user will be to
try
> "-ffast-math" and if don't work and he is really interested in the
> perofrmance, he will try the suboptions.
>
> GLIBC for instance does inlining of some math functions on -ffast-math
that
> gives inexact results.
Thanks for bringing this up.  This is an example of inflicting too many
dangerous shortcuts
under one option; worse, an option which kicks in by default already
at -O, in violation
of the rule you quoted above.  I myself use a saner version of
<mathinline.h>.  It allows
gcc-3.1 to out-perform g77, without all those crashes on exceptional
arguments.  (OT)
I don't see the decisions about options made by gcc having much
influence on glibc, nor
should the decisions made for glibc influence gcc when they don't make
sense.  I see a
need now for some changes in math library support for P4, but the level
of interest may
be insufficient.
>
> I agree with idea of adding new options to control this feature, but
as
> options of -ffast-math, as
the -funsafe-math-optimizations, -ftrapping-math
> and -ferrno-math is currently implemented.
This seems OK if we have a documented way to turn off individually the
sub-options
of -ffast-math.  I have been experimenting this morning with -ffast-math
and trying to
over-ride the individual options.  I think it works,
but -march=pentiumpro -ffast-math
has lost its good effect for P-III in g77-3.1 now that short IF blocks
are producing
jumps out of line.  gcc has not picked up this behavior, but I see now
that -ffast-math
is no longer required to obtain efficient code for floating point
compare and branch.
> >
> > When Honza and I first discussed this, and also the transformation
> >
> > for(i=0;i<n;++i)
> >     a[i]=b[i]/c;
> >
> > to
> >
> > for(i=0;i<n;++i)
> >     a[i]=b[i]*(1/c);
> I've already implemented this transformation.
> >
> > I mentioned that these would put too many risks in the -ffast-math
> > category.  I would like to see -ffast-math permit only those
> > optimizations outside of IEEE compliance which are generally
expected
> > (e.g. according to Fortran standard).
> You do have experience with this options.  Do you know examples of
programs
> where it fails?
The pre-inversion may make noticeable differences in accuracy, and those
may well
be of concern.  It shouldn't fail on an IEEE-compliant architecture, in
the normal
course of events.  As others pointed out, the re-association of division
makes
opportunities for changes in over- and under-flow behavior, from which
IA32
architectures will no longer be protected, with the increasing use of
SSE
instructions.

In a large application, if something breaks when turning on a family of
unsafe
optimizations, when there is no documented way of turning them on
individually,
the only practical solution may be to do without the optimizations.  I
have spent
weeks on a binary search to find out which methods in a C++ application
were
breaking with optimization, on a platform for which g++ is not
available.
>
> For instance we already do reassociation with -ffast-math
> >
> > For gcc-3.1, I would like to see an additional switch to permit
> > optimizations such as the ones on floating point division mentioned
> > above.  I don't care about the name, but it should be more mnemonic
than
> > the ones used by commercial compilers; something like -ffast-div.
> This sounds resonable name.  If no one complains, I will add it in the
> sense mentioned above.
>
> Honza