Re: associative law in combine

Re: associative law in combine

[Jan Hubicka]

> Jan Hubicka wrote:
> 
> > > Sure, but not in fold-CONST.c :-)
> > OK, what is the apropriate place for that then? We simply need it to be done
> > at tree level.  It is FOLD-const after all :)
> 
> Unfortunately, I don't know.
> 
> Perhaps just asking it on the list is best.
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?

Honza

Re: associative law in combine

[Dima Volodin]

On Tue, 17 Jul 2001 21:21:25 +0200, you wrote:

>> Jan Hubicka wrote:
>> 
>> > > Sure, but not in fold-CONST.c :-)
>> > OK, what is the apropriate place for that then? We simply need it to be done
>> > at tree level.  It is FOLD-const after all :)
>> 
>> Unfortunately, I don't know.
>> 
>> Perhaps just asking it on the list is best.
>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?

Are you sure you want to do that at all? These two expressions have
different overflow properties and might produce different results.

>Honza

Dima

Re: associative law in combine

[Joern Rennecke]

> 
> > Jan Hubicka wrote:
> > 
> > > > Sure, but not in fold-CONST.c :-)
> > > OK, what is the apropriate place for that then? We simply need it to be done
> > > at tree level.  It is FOLD-const after all :)
> > 
> > Unfortunately, I don't know.
> > 
> > Perhaps just asking it on the list is best.
> 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.

Re: associative law in combine

[Toon Moene]

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.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - 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)

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

[Jan Hubicka]

> 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

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

[Tim Prince]

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

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

[Jan Hubicka]

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

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

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

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

[Tim Prince]

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

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

[Jan Hubicka]

> 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

The mathinline is mostly mess.  I was thinking about rewriting it myself.
It seems to make sense to make target specific builtins for the i387
features the header needs and use them, instead of using mostly unusable
i387 inline assembly.

If you have sanified version and you can get the copyring issues,
please try to contribute the changed to glibc.

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

The description quoted above states, that FLAG_FAST_MATH is defined and
so glibc is correct IMO to change the behaviour.

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

OK, I will document the new options in -ffast-math, as we document these
on -Ox and send a patch shortly.
> 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.

We may jump into something like -fapproximate-fp-math allowing transformation
with loss of effciency if that makes sense.
> 
> 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,

You can turn them individually and if they are not documented, I will do
so shortly.

Honza

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

[Tim Prince]

----- 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 10:24 AM
Subject: Re: What is acceptable for -ffast-math? (Was: associative law
in combine)


> The mathinline is mostly mess.  I was thinking about rewriting it
myself.
> It seems to make sense to make target specific builtins for the i387
> features the header needs and use them, instead of using mostly
unusable
> i387 inline assembly.
glibc as a whole is so dependent on i386 assembly that it would be a
major project to change.  It might be interesting to include direct
support for more math intrinsics in gcc, but that begins to encroach on
the traditional separation between gcc and support libraries.  I suppose
this would involve built-ins for frexp(), ldexp() et al. in each
supported precision.  I fear that a noticeable amount of efficiency
could be lost, and we would remain with the question of full accuracy
and safety vs speed in certain cases.  A beginning would be to organize
mathinline.h so as to be based on such a group of builtins in order to
test them in the current framework.  This project may not offer
sufficient return without assurance of glibc taking advantage of it and
becoming more portable.
>
> If you have sanified version and you can get the copyring issues,
> please try to contribute the changed to glibc.
I took this far enough with the glibc maintainers to see that their
point of view does not allow introduction of any "safety features."  Now
I will be even further away, wanting to improve support for P4.
> >
> > 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,
>
> You can turn them individually and if they are not documented, I will
do
> so shortly.

Thanks
>
> Honza

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

[Jan Hubicka]

> glibc as a whole is so dependent on i386 assembly that it would be a
> major project to change.  It might be interesting to include direct
Gcc currently have an method to add machine dependent builtins used
by the SSE code.  I think in same sense we can add machine dependent
builtins for the few remaining i387 instructions we don't generate
directly and then use mathinline.h to do right job converting them
to 'C' way.

I believe this is clean solution.
> support for more math intrinsics in gcc, but that begins to encroach on
> the traditional separation between gcc and support libraries.  I suppose
> this would involve built-ins for frexp(), ldexp() et al. in each
> supported precision.  I fear that a noticeable amount of efficiency
I must say I don't follow the above...
> could be lost, and we would remain with the question of full accuracy
> and safety vs speed in certain cases.  A beginning would be to organize
> mathinline.h so as to be based on such a group of builtins in order to
> test them in the current framework.  This project may not offer
This sounds exactly what I say :) So we seems to be in tune.

Honza
> sufficient return without assurance of glibc taking advantage of it and
> becoming more portable.
> >
> > If you have sanified version and you can get the copyring issues,
> > please try to contribute the changed to glibc.
> I took this far enough with the glibc maintainers to see that their
> point of view does not allow introduction of any "safety features."  Now
> I will be even further away, wanting to improve support for P4.
I

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

[Linus Torvalds]

In article < 004501c117f4$84a48c80$9865fea9@timayum4srqln4 > you write:
>
>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.

Note that with FP math, especially with C, there are mainly two kinds of
people:

 - those who know and care about underflows, overflows and precision.
   They _sometimes_ also want exact IEEE semantics, but not necessarily.
 - those who don't, and don't want to, and just want fast code.

Why not make this easier for the user:

 - default to non-IEEE, but "reasonably safe". Allow optimizations that
   underflow or aren't precise to ULP - or optimizations that extend the
   range of calculations (ie keep things in "double" or "long double"
   longer than strictly allowed), but don't allow optimizations that can
   make the range of operations smaller (ie extra traps are bad).

 - make "-ffast-math" mean exactly that: fast.  Even at the expense of
   being even more incorrect, ie allowing optimizations that might
   overflow. Let's face it - they are quite rare, especially in code
   that doesn't care. Make "-ffast-math" be the generic "if you don't
   know, and if you don't care, use this option" for people who just
   want ultimate speed for their quake3 thing.

 - make the people who _do_ know what they are doing and _do_ know what
   the options mean have extra options on just how careful they can be.
   It's silly and counter-productive to assume that most people would
   know what "-ffast-div" is.

So for real math, you'd have

 - "-mieee": This turns us into anal animals, and often implies using
   different math libraries etc too. No "reasonable safe" optimizations
   except the ones explicitly allowed by standards.

 - "-ffloat-precision": allow optimizations that might lose precision.

 - "-ffloat-div-reciprocal": allow optimizations with turning divides
   into reciprocals etc.

  ...

But don't make "-ffast-math" imply "it's still safe". Please. 

So do allow Honza's optimization under fast-math. Don't allow it by
default, and NEVER allow it with "-mieee" unless we start doign the
Fortran thing.

That way, we can also have a simple benchmarking rule: use "-O2
-ffast-math" for benchmarks. No need to tell people about the latest
"-ffloat-random-optimization" of the day, which changes with compiler
releases anyway.

		Linus

Re: associative law in combine

[Joern Rennecke]

> issue in my reply to you.  Because overflow can only be determined at
> compile time with constants, this conversion cannot be right for
> variables.

Actually, as with most rules, there is an exception here: if b and c
are widened, or are constants that fit into a type with less precision,
we can widen before the multiply, or, even better, we can use a wideining
multiply (if available).

e.g.:

 long long a;
 int b, c;

or:

 double a;
 float b, c;

or:

 double a;
 float b;

 a = a / b / 42

However, that might be to rare to be worth the effort.