[llvm-commits] [llvm] r158956 - in /llvm/trunk: include/llvm/Target/TargetOptions.h lib/CodeGen/SelectionDAG/DAGCombiner.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp lib/Target/ARM/ARMInstrInfo.td test/CodeGen/ARM/fusedMAC.ll test/CodeGen

[Lang Hames]

Hi Hal,

Why are we exposing the standard vs. strict choice at the LLVM level?


Because we've started exposing "potential fusability" at the LLVM level.
The llvm.fmuladd intrinsic (and whatever we eventually replace it with)
indicates that we're willing to accept formation of a fused operation (but
it's not guaranteed). I envisaged the strict mode of this flag as being
useful for disabling this fusing.

I intend to have Clang not produce fmuladd nodes when
-ffused-fp-ops=strict, but I still think having this option at the LLVM
level is useful for people who want to store and codegen bit codes with
different optimization settings.


> > Note: This option only controls formation of fused ops by the
> > optimizers.  Fused operations that are explicitly requested (e.g. FMA
> > via the llvm.fma.* intrinsic) will always be honored, regardless of
> > the value of this option.
>
> This seems to contradict the code below where you only select the
> ISD::FMA node if the mode is not strict.
>

That's for llvm.fmuladd, which as noted above represents a potentially
fusable operation. An llvm.fma intrinsic will always be codegen'd to an
ISD::FMA regardless of the setting of -fused-fp-ops

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120621/4fd38fb2/attachment.html>