[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

Hal Finkel hfinkel at anl.gov
Thu Jun 21 20:27:42 PDT 2012


On Thu, 21 Jun 2012 19:52:54 -0700
Lang Hames <lhames at gmail.com> wrote:

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

Makes sense. Thanks!

 -Hal

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



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list