[llvm-commits] [llvm] r157737 - in /llvm/trunk: lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp lib/Target/X86/X86CodeEmitter.cpp lib/Target/X86/X86InstrFMA.td lib/Target/X86/X86InstrInfo.cpp lib/Target/X86/X86InstrInfo.h lib/Target/X86/X86Subta

[Stephen Canon]

On Jun 1, 2012, at 4:07 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> I was under the impression from Lang's messages that these are somewhat
> decoupled issues. The motivation for Lang's design is that C only allows
> contractions of operations that are within the same
> C-language statement. As only the frontend is aware of C statement
> boundaries, it will be the responsibility of the frontend to form the
> contractions where it can.

Right.  The point of llvm.fmuladd is to correctly model FP_CONTRACT on/off.

> On the other hand, some kind of "fast math" mode should allow FMA
> formation from operations that come from different statements; in other
> words, in general. In the PowerPC backend, for example, we have FMA
> patterns that are guarded by TM.Options.NoExcessFPPrecision. I am not
> responsible for this, but I think this is the right thing to do.

Yes, we definitely want to have a third mode of operation in which FMA formation is freely licensed wherever the target model says it is beneficial to performance.  This third mode doesn't need to have any source language information, so it can be totally independent of the frontend and should be much simpler to implement.

I agree with your assessment that ExcessFPPrecision is pretty close to what is needed for such a mode -- both FMA formation and excess precision are transformations which make some intermediate results more accurate, are backwards-stable, can result in asymmetries, and occasionally produce slightly less accurate results when those asymmetries conspire against the calculation.

- Steve