public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <004501c117f4$84a48c80$9865fea9@timayum4srqln4> (raw)
In-Reply-To: <20010718104420.E29584@atrey.karlin.mff.cuni.cz>

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

  reply	other threads:[~2001-07-28 23:04 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010716224423.F29145@atrey.karlin.mff.cuni.cz>
     [not found] ` <3B547DF4.7F39BF61@moene.indiv.nluug.nl>
     [not found]   ` <20010717200629.E5166@atrey.karlin.mff.cuni.cz>
     [not found]     ` <3B5489F1.54DE59CE@moene.indiv.nluug.nl>
     [not found]       ` <20010717205837.I5166@atrey.karlin.mff.cuni.cz>
     [not found]         ` <3B548CBF.DDD59F97@moene.indiv.nluug.nl>
     [not found]           ` <20010717211516.N5166@atrey.karlin.mff.cuni.cz>
     [not found]             ` <3B548FAA.E174E765@moene.indiv.nluug.nl>
2001-07-17 12:23               ` associative law in combine Jan Hubicka
2001-07-17 15:41                 ` Dima Volodin
2001-07-17 15:59                 ` Joern Rennecke
2001-07-18  1:01                   ` Toon Moene
2001-07-18  1:47                     ` What is acceptable for -ffast-math? (Was: associative law in combine) Jan Hubicka
2001-07-28 23:04                       ` Tim Prince [this message]
2001-07-29  6:33                         ` Jan Hubicka
2001-07-29 10:18                           ` Tim Prince
2001-07-29 10:26                             ` Jan Hubicka
2001-07-29 12:11                               ` Tim Prince
2001-07-29 12:17                                 ` Jan Hubicka
2001-07-29 10:50                         ` Linus Torvalds
2001-07-18 11:30                     ` associative law in combine Joern Rennecke
2001-07-29 12:52 * Re: What is acceptable for -ffast-math? (Was: associative lawin combine) Linus Torvalds
2001-07-29 14:03 ` What is acceptable for -ffast-math? (Was: associative law incombine) Stephen L Moshier
2001-07-29 21:17   ` What is acceptable for -ffast-math? (Was: associative law in combine) Fergus Henderson
2001-07-30  0:23     ` Gabriel Dos Reis
2001-07-29 14:22 dewar
2001-07-29 21:33 What is acceptable for -ffast-math? (Was: associative law incombine) Linus Torvalds
2001-07-30 14:43 ` What is acceptable for -ffast-math? (Was: associative law in combine) Alexandre Oliva
2001-07-30 15:45   ` Neil Booth
2001-07-30 16:03     ` Alexandre Oliva
2001-07-30 16:11       ` Neil Booth
2001-07-30 16:28         ` Alexandre Oliva
2001-07-30 19:08   ` Joern Rennecke
2001-07-30 19:22     ` Alexandre Oliva
2001-07-30 19:29       ` Gabriel Dos Reis
2001-07-30 19:34         ` Alexandre Oliva
2001-07-30 19:54           ` Gabriel Dos Reis
2001-07-30 19:27     ` Gabriel Dos Reis
2001-07-30  5:57 dewar
2001-07-30  6:00 dewar
2001-07-30 13:08 ` Toon Moene
2001-07-30  6:01 dewar
2001-07-30  6:53 ` Tim Hollebeek
2001-07-30  6:14 dewar
2001-07-30  8:30 ` Kevin Handy
2001-07-30  8:59 mike stump
2001-07-30 11:37 What is acceptable for -ffast-math? (Was: associative law incombine) Linus Torvalds
2001-07-30 11:53 ` What is acceptable for -ffast-math? (Was: associative law in combine) Gabriel Dos Reis
2001-07-30 18:40   ` Olivier Galibert
2001-07-30 19:06     ` Gabriel Dos Reis
2001-07-31  1:35   ` Linus Torvalds
2001-07-31  2:04     ` Gabriel Dos Reis
2001-07-31  2:35       ` Olivier Galibert
2001-07-31  2:58         ` Gabriel Dos Reis
2001-07-31 18:10       ` Linus Torvalds
2001-07-30 11:52 dewar
2001-07-30 12:26 dewar
2001-07-30 13:10 dewar
2001-07-30 15:29 dewar
2001-07-30 15:39 ` Toon Moene
2001-07-30 16:11 dewar
2001-07-30 16:29 ` Alexandre Oliva
2001-07-31  8:13   ` Kevin Handy
2001-07-30 18:00 dewar
2001-07-30 18:25 ` Joe Buck
2001-07-30 18:02 dewar
2001-07-30 18:08 dewar
2001-07-30 18:38 dewar
2001-07-30 18:39 dewar
2001-07-30 19:46 dewar
2001-07-30 20:00 ` Gabriel Dos Reis
2001-07-30 20:20   ` Alexandre Oliva
2001-07-30 20:25     ` Gabriel Dos Reis
2001-07-30 20:54 dewar
2001-07-30 21:11 ` Gabriel Dos Reis
2001-07-30 21:39 ` Joern Rennecke
2001-07-30 21:13 dewar
2001-07-30 21:34 ` Gabriel Dos Reis
2001-07-30 21:43   ` Joern Rennecke
2001-07-30 21:53     ` Gabriel Dos Reis
2001-08-03  7:12       ` Nick Ing-Simmons
2001-08-01  8:55   ` Theodore Papadopoulo
2001-08-01  9:15     ` Gabriel Dos Reis
2001-08-01 11:21       ` Theodore Papadopoulo
2001-08-01 11:44         ` Gabriel Dos Reis
2001-08-01  9:24     ` Tim Hollebeek
2001-08-01  9:54       ` What is acceptable for -ffast-math? (Was: associative law incombine) Linus Torvalds
2001-08-01 10:26         ` Gabriel Dos_Reis
2001-08-01 11:13           ` What is acceptable for -ffast-math? (Was: associative law in combine) Alexandre Oliva
2001-08-01 11:36             ` Gabriel Dos Reis
2001-08-01 12:07               ` Alexandre Oliva
2001-08-01 13:21                 ` Gabriel Dos_Reis
2001-08-01 14:20                   ` Toon Moene
2001-07-31  7:26 dewar
2001-07-31 15:57 ` Toon Moene
2001-07-31 21:55   ` Tim Prince
2001-08-03  6:12 ` Per Abrahamsen
2001-07-31  7:59 mike stump
2001-07-31  8:19 mike stump
2001-07-31  8:35 dewar
2001-07-31  8:36 mike stump
2001-07-31  8:36 dewar
2001-07-31  8:37 dewar
2001-07-31  9:22 mike stump
2001-07-31 16:38 dewar
2001-07-31 17:37 dewar
2001-07-31 18:12 What is acceptable for -ffast-math? (Was: associative law incombine) Linus Torvalds
2001-07-31 20:55 ` What is acceptable for -ffast-math? (Was: associative law in combine) Gabriel Dos Reis
2001-07-31 18:15 dewar
2001-07-31 18:20 dewar
2001-07-31 18:50 ` Joern Rennecke
2001-07-31 21:27   ` Tim Prince
2001-07-31 18:23 dewar
2001-07-31 19:10 dewar
2001-08-01  3:02 Vincent Penquerc'h
2001-08-01  6:04 dewar
2001-08-01  6:48 ` Vincent Penquerc'h
2001-08-03  0:46 ` Eric W. Biederman
2001-08-01  6:52 dewar
2001-08-01  9:58 What is acceptable for -ffast-math? (Was: associative law incombine) Gabriel Dos_Reis
2001-08-01 10:08 ` Wolfgang Bangerth
2001-08-01 11:12   ` Gabriel Dos_Reis
2001-08-01 11:27     ` What is acceptable for -ffast-math? (Was: associative law in combine) Theodore Papadopoulo
2001-08-01 11:47       ` Gabriel Dos_Reis
2001-08-03  7:32         ` Nick Ing-Simmons
2001-08-03  6:01     ` Per Abrahamsen
2001-08-01  9:59 dewar
2001-08-01 10:04 dewar
2001-08-01 10:28 ` Gabriel Dos_Reis
2001-08-01 10:05 dewar
2001-08-01 10:13 dewar
2001-08-01 10:38 dewar
2001-08-01 10:39 dewar
2001-08-01 12:06 Phil Edwards
2001-08-01 19:04 Carlo Wood
2001-08-02  3:37 Vincent Penquerc'h
2001-08-03 14:48 dewar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004501c117f4$84a48c80$9865fea9@timayum4srqln4' \
    --to=tprince@computer.org \
    --cc=amylaar@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jh@suse.cz \
    --cc=toon@moene.indiv.nluug.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).