This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]