public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* -ffast-math and floating point reordering
@ 2004-03-25  6:03 Joe Buck
  2004-03-25  6:05 ` Ian Lance Taylor
                   ` (3 more replies)
  0 siblings, 4 replies; 30+ messages in thread
From: Joe Buck @ 2004-03-25  6:03 UTC (permalink / raw)
  To: gcc

OK, let's start a thread under the right title.

The question under consideration is how, if at all, the -ffast-math flag
should effect the evaluation of a+b+c or (a+b)+c .  It turns out that
there was a lot of confusion as to what the rules are, for various
languages.

Summary (credit to Joseph Myers, Gaby Dos Reis, and Toon Moene): for the
case where a, b, and c are really expressions, these expressions can be
evaluated in any order.  At that point:

Fortran:for a+b+c we can add in any order.  For (a+b)+c parentheses must
        be respected.

C++:	not only are parentheses respected, but a+b+c is (a+b)+c

Ada:	the 1983 LRM seems to say that the rule is the same as for C++:

	"... for a sequence of operators of the same precedence level, the
	operators are associated in textual order from left to right;
	parentheses can be used to impose specific associations"

	( http://archive.adaic.com/standards/83lrm/html/lrm-04-05.html#4.5 )

C:	if IEEE conformant behavior is promised (by defining
	__STDC_IEC_559__), it's like C++, but "the implementation can state
	that the accuracy of floating-point operations is unknown" if
	this symbol is not defined.

K&R C:	compilers could reorder FP operations at will; the user had to
        use explicit temporaries to defeat this.

Java:   not only do operators of equal precedence associate from left to
	right, but so does order of evaluation.

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?

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.

^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: -ffast-math and floating point reordering
@ 2004-03-26 11:20 Bradley Lucier
  0 siblings, 0 replies; 30+ messages in thread
From: Bradley Lucier @ 2004-03-26 11:20 UTC (permalink / raw)
  To: bosch; +Cc: Bradley Lucier, gcc

In

http://gcc.gnu.org/ml/gcc/2004-03/msg01492.html

Geert Bosch writes

> This is a good point, and it also serves as an illustration
> of weaknesses in the "just add another command-line option" philosophy.
> For example, in writing various elementary floating-point functions, it
> definitely is necessary to prevent unsafe transformations in order to
> attain accuracy requirements for the entire domain of the function.
>
>
> On the other hand, it is also desirable in many cases to inline these
> functions, especially when one of the operands is a constant. How can
> we specify that this code that relies on strict semantics will not
> be affected by the command-line options.
>
>
> A similar issue exists the other way around. There may be library
> functions where the various transformations are known to be safe,
> and which may benefit from them. Think of a graphics routines for
> coordinate transformations for example.
>
>
> One solution seems to allow having tree-level operations for addition,
> multiplications etc. that specify wether they are
>   - associative
>   - communicative
>   - potentially trapping
>   - supporting non-finite value semantics
>   - supporting non-default rounding
>
>
> This way front ends can set these attributes depending on language
> rules and/or constructs in the source specifying certain behavior.

Another, perhaps equivalent approach, would be to have lexically scoped 
"compilation environments" for code trees.  These compilation 
environments would be set up at the point where the tree is defined; if 
a function is inlined, it would be inlined with its lexically-defined 
compilation environment intact.  The tree is then transformed using the 
rules of the associated compilation environment.

This is done now in the Gambit-C Scheme compiler.  If a function is 
declared to be compiled without runtime error checking, then this 
property is carried wherever this function is inlined.  This may be 
clearer when compiler options are declared using inline pragmas rather 
than with compiler switches attached to entire files.

Brad

^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: -ffast-math and floating point reordering
@ 2004-03-26 18:33 Robert Dewar
  0 siblings, 0 replies; 30+ messages in thread
From: Robert Dewar @ 2004-03-26 18:33 UTC (permalink / raw)
  To: Joe.Buck, law; +Cc: gcc

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

It's a significant goof for a Fortran compiler not to remember whether
parens are used. GNAT remembers not only if parens were used, but how
many levels, but that's required due to obscure requirements in
conformance rules, and of course it is not passed on to the back end
since (a) that's not necessary, it does not affect semantics in Ada
and in any case (b) there is no way to do that.

> First I'd like to come out in favor of having a flag to turn on FP
> reassociation.

Note that there are two levels here. One is about what the Fortran
standard allows in the absence of parens, which is rearrangement
within an expression. The more extensive permission is to rearrange
over a series of separately computed expressions.

^ permalink raw reply	[flat|nested] 30+ messages in thread
* Re: -ffast-math and floating point reordering
@ 2004-03-26 22:22 Chris Lattner
  2004-03-26 22:27 ` Chris Lattner
  0 siblings, 1 reply; 30+ messages in thread
From: Chris Lattner @ 2004-03-26 22:22 UTC (permalink / raw)
  To: Richard Guenther; +Cc: Diego Novillo, Joe Buck, Jeff Law, gcc


>> Yeah.  We sort of discussed adding additional PLUS_EXPR operands and/or
>> attributes at last year's summit.  But I think that was the extent of
>> it.  IIRC, there was beer involved, so I doubt anybody was taking notes.

> Hmm, this is usually the point where we get the LLVM people tell us what
> they are doing here...

Okay, first, you must understand that LLVM is under vastly different
constraints than GCC is.  It makes little sense to have a -ffast-math mode
in LLVM.  What would happen when you link two .o files with different
settings?  At best the flag would just be cleared.

That said, we don't have an implemented solution to this either at
present.  My plan is to add a new "fpadd" or "strictadd" instruction or
something similar that provides strict FP semantics.  The existing LLVM
"add" instruction on fp would then be relaxed to allow allow the
equivalent of -ffast-math operations.  This allows different translation
units to be linked together without losing a notion of which operations
are strict and which ones are not.

This also allows individual translation units to mix different semantics
as well.  For example, Java has strictfp, and fortran has the parenthesis
issue.  In a fortran front-end that preserved the appropriate information,
this shows how the code generation would differ:

 x = a + b + c

   %t1 = add double %a, %b
   %x = add double %t1, %c

 x = (a + b) + c

   %t = fpadd double %a, %b
   %x = add double %t, %c

 x = a + (b + c)

   %t = fpadd double %b, %c
   %x = add double %t, %a

That's the idea.  Note again, that this has not been implemented, largely
because no one has taken it up (it should be entirely straight-forward).
The other advantage of doing this is that we would be able to change code
like this:

  // X + 0 --> X
  if (I.getOpcode() == Instruction::Add &&
     !I.getType()->isFloatingPoint() &&    // -0 + +0 = +0, so it's not a noop
      RHS == Constant::getNullValue(I.getType()))
    return ReplaceInstUsesWith(I, LHS);

With code that looks like this:

  // X + 0 --> X
  if (I.getOpcode() == Instruction::Add &&
      RHS == Constant::getNullValue(I.getType()))
    return ReplaceInstUsesWith(I, LHS);

... leading to cleaner and easier to maintain code.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

^ permalink raw reply	[flat|nested] 30+ messages in thread
end of thread, other threads:[~2004-03-27  0:48 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-25  6:03 -ffast-math and floating point reordering 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
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

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