This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -ffast-math and floating point reordering
- From: Chris Lattner <sabre at nondot dot org>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: Diego Novillo <dnovillo at redhat dot com>,Joe Buck <Joe dot Buck at synopsys dot com>, Jeff Law <law at redhat dot com>,<gcc at gcc dot gnu dot org>
- Date: Fri, 26 Mar 2004 14:19:35 -0600 (CST)
- Subject: Re: -ffast-math and floating point reordering
>> 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/