From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Tim Prince" <tprince@computer.org>
To: "Jan Hubicka" <jh@suse.cz>, "Toon Moene" <toon@moene.indiv.nluug.nl>
Cc: "Joern Rennecke" <amylaar@redhat.com>, "Jan Hubicka" <jh@suse.cz>, <gcc@gcc.gnu.org>
Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
Date: Sat, 28 Jul 2001 23:04:00 -0000
Message-id: <004501c117f4$84a48c80$9865fea9@timayum4srqln4>
References: <200107172259.f6HMxYU31134@phal.cambridge.redhat.com> <3B55427F.4790646A@moene.indiv.nluug.nl> <20010718104420.E29584@atrey.karlin.mff.cuni.cz>
X-SW-Source: 2001-07/msg01860.html

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


> > Joern Rennecke wrote:
> >
> > > > > Jan Hubicka wrote:
> >
> > > > OK, so to speak loud - where is the proper place to convert
> > > > a/b/c to a/(b*c) at tree level. fold-const or some other?
> > >
> > > Only if b and c are constants, the operations are floating point,
and
> > > b can be multiplied with c without loss of precision or overflow.
> > > Or if b and/or c is a power of two, and b can be multiplied with c
without
> > > overflow.
> >
> > Joern is right, Jan.  One can argue about the loss of precision
(under
> > unsafe math optimisations), but not the overflow.  I overlooked that
> > issue in my reply to you.  Because overflow can only be determined
at
> > compile time with constants, this conversion cannot be right for
> > variables.
> OK, I believe, that our concept of unsafe_math_optimizations allows
such
> transformation, but I see, that the line between acceptable
> unsafe_math_optimization and unacceptable one is pretty fragine.
>
> In case -ffast-math is not enought to ask for such transformation,
> we probably should invent switch for that.  This change (plus the
> other changes to avoid divisions) seems to play important role
> on optimizing some FP software (due to extreme cost of fp division).
>
> Honza

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.

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 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).

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.