public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: law@redhat.com
To: Joe Buck <Joe.Buck@synopsys.COM>
Cc: gcc@gcc.gnu.org
Subject: Re: -ffast-math and floating point reordering
Date: Fri, 26 Mar 2004 18:18:00 -0000	[thread overview]
Message-ID: <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com> (raw)
In-Reply-To: Your message of "Wed, 24 Mar 2004 17:07:19 PST." <20040324170719.A12420@synopsys.com>

In message <20040324170719.A12420@synopsys.com>, Joe Buck writes:
 >If -ffast-math is not specified, we should follow the language standards.
 >First question: can tree-ssa distinguish, for Fortran, whether parentheses
 >were present and so whether reordering is allowed?
No.  The front-ends don't pass enough information around in the tree nodes
to know when such changes are safe/unsafe.  Even if the information existed
none of the optimizers would know how to use it (at least initially).


 >If -ffast-math is specified, what should we do?  One option is to use the
 >K&R rule and free-associate at will.  I feel uncomfortable with that
 >because of the major loss in accuracy that can result.  If, however, we
 >implement support for the Fortran rules, one option would be to relax
 >order of evaluation when there are no parentheses (like Fortran), another
 >would be to just leave the order the same.
First I'd like to come out in favor of having a flag to turn on FP
reassociation.

The question then becomes whether or not -ffast-math ought to turn that
flag on.  I'm neither a significant user or expert in FP arithmetic.  So
I've got no strong opinions here.


jeff


  parent reply	other threads:[~2004-03-26 16:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-25  6:03 Joe Buck
2004-03-25  6:05 ` Ian Lance Taylor
2004-03-25 11:27   ` Robert Dewar
2004-03-25 11:31     ` Ian Lance Taylor
2004-03-25 11:55       ` Ben Elliston
2004-03-25 12:37       ` Robert Dewar
2004-03-25 10:22 ` Robert Dewar
2004-03-25 18:28   ` Joe Buck
2004-03-25 18:38     ` Dave Korn
2004-03-26 20:06     ` Robert Dewar
2004-03-26 20:18       ` Joe Buck
2004-03-25 16:12 ` Paul Koning
2004-03-25 18:46   ` Dale Johannesen
2004-03-25 20:11     ` Geert Bosch
2004-03-27  1:51     ` Robert Dewar
2004-03-27  2:39       ` Dale Johannesen
2004-03-26 18:18 ` law [this message]
2004-03-26 18:37   ` Joe Buck
2004-03-26 18:46     ` Diego Novillo
2004-03-26 19:03       ` Richard Guenther
2004-03-26 19:54         ` Fariborz Jahanian
2004-03-26 20:19         ` law
2004-03-26 22:08           ` Joe Buck
2004-03-27  0:42             ` Richard Henderson
2004-03-26 22:12     ` Joseph S. Myers
2004-03-26 21:48   ` Laurent GUERBY
2004-03-26 11:20 Bradley Lucier
2004-03-26 18:33 Robert Dewar
2004-03-26 22:22 Chris Lattner
2004-03-26 22:27 ` Chris Lattner

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=200403261621.i2QGLQ7X014994@speedy.slc.redhat.com \
    --to=law@redhat.com \
    --cc=Joe.Buck@synopsys.COM \
    --cc=gcc@gcc.gnu.org \
    /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).