Hi Hal,<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why are we exposing the standard vs. strict choice at the LLVM level?</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Note: This option only controls formation of fused ops by the<br>
> optimizers.  Fused operations that are explicitly requested (e.g. FMA<br>
> via the llvm.fma.* intrinsic) will always be honored, regardless of<br>
> the value of this option.<br>
<br>
</div>This seems to contradict the code below where you only select the<br>
ISD::FMA node if the mode is not strict.<br></blockquote><div><br></div><div>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</div>
<div><br></div><div>Cheers,</div><div>Lang.</div></div></div>