public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joe Buck <Joe.Buck@synopsys.COM>
To: law@redhat.com
Cc: gcc@gcc.gnu.org
Subject: Re: -ffast-math and floating point reordering
Date: Fri, 26 Mar 2004 18:37:00 -0000	[thread overview]
Message-ID: <20040326094202.A2838@synopsys.com> (raw)
In-Reply-To: <200403261621.i2QGLQ7X014994@speedy.slc.redhat.com>; from law@redhat.com on Fri, Mar 26, 2004 at 09:21:26AM -0700

On Fri, Mar 26, 2004 at 09:21:26AM -0700, law@redhat.com wrote:
> 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).

This should be considered a design bug, as it forces GCC to be inferior
to competing Fortran compilers.

One possible representation in GIMPLE would be a flag indicating that a
temporary can be, well, I'll call it "refactored" (feel free to suggest a
better word).  That is, given GIMPLE code like

	t1 = a + b;
	t2 = t1 + c;
	e = t2 + d;

if the original Fortran input was

   	e = a + b + c + d

then t1 and t2 would be tagged as refactorable, while if the original
input were

	d = ((a + b) + c) + d

then t1 and t2 would not be so tagged.  In the first case, we would
probably want to produce

	t1 = a + b;
	t2 = c + d;
	e = t1 + t2;

since the first two additions can now be performed in parallel.  But
this transformation is not legal in the second case.

For temporaries marked as refactorable, optimizers are allowed to replace
use of the temporary by the expression that computes it, and do
transformations on that expression, even if the tranformation doesn't
guarantee that roundoffs and overflows will be the same.  If the temporary
is not marked as refactorable, this is not permitted.

With such a rule, the language-independent middle end can implement
Fortran or C semantics correctly, and it would be possible to relax the
rules in a controlled manner as well:. the user could ask the C front
end to implement the Fortran rules (respect parentheses but otherwise
allow rearrangement), or the K&R rules (all rearrangements that are
correct for real numbers are allowed), but by default the compiler would
follow the standard.





  reply	other threads:[~2004-03-26 17:42 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
2004-03-26 18:37   ` Joe Buck [this message]
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=20040326094202.A2838@synopsys.com \
    --to=joe.buck@synopsys.com \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.com \
    /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).