<div dir="ltr">Out of curiosity, what is the use-case for isFMAFasterThanMulAndAdd?  If a target declares that FMA is actually slower for a given type, why not just declare it as illegal for that type?  Wouldn't that accomplish the same thing without another target hook?  I feel like I'm missing something here.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 2:40 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Cameron McInally" <<a href="mailto:cameron.mcinally@nyu.edu">cameron.mcinally@nyu.edu</a>><br>
> To: "Andrew Booker" <<a href="mailto:andrew.booker@arm.com">andrew.booker@arm.com</a>><br>
> Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
> Sent: Friday, January 11, 2013 12:37:07 PM<br>
> Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic<br>
><br>
><br>
> On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <<br>
> <a href="mailto:andrew.booker@arm.com">andrew.booker@arm.com</a> > wrote:<br>
><br>
><br>
><br>
> The fmuladd intrinsic is described as saying that a multiply and<br>
> addition sequence can be fused into an fma instruction "if the code<br>
> generator determines that the fused expression would be legal and<br>
> efficient". ( <a href="http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic" target="_blank">http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic</a> )<br>
><br>
> I've spent a bit of time puzzling over how a code generator is<br>
> supposed<br>
> to know if it's legal to generate an fma instead of a multiply and<br>
> add<br>
> - surely that's something for the frontend to determine, based on the<br>
> FP_CONTRACT setting, and not something for the code generator to work<br>
> out?<br>
><br>
> However, recently I came across<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582</a><br>
> 22.html<br>
> which explains that "legal" in the above definition doesn't mean<br>
> legal<br>
> from the point of view of the source language, but simply means<br>
> whether<br>
> or not the target architecture has an fma instruction. The thread<br>
> also<br>
> talks about updating the documentation to clarify this, but that<br>
> doesn't seem to have happened.<br>
><br>
> Assuming that the thread I've linked to is correct, would it be<br>
> possible to clarify the IR spec accordingly? I think that the current<br>
> use of the word "legal" is misleading.<br>
><br>
><br>
><br>
><br>
> Hey Andrew,<br>
><br>
><br>
> I believe that the term "legal" is associated with the Legalize<br>
> phase. Please see:<br>
><br>
><br>
> <a href="http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase" target="_blank">http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase</a><br>
><br>
><br>
> The x86 backend has a good example of this in<br>
> llvm/lib/Target/X86/X86ISelLowering.cpp:<br>
><br>
><br>
><br>
> > if (Subtarget->hasFMA()) {<br>
> > // Support FMAs!<br>
> > setOperationAction(ISD::FMA, MVT::f64, Legal);<br>
> > setOperationAction(ISD::FMA, MVT::f32, Legal);<br>
> > }<br>
> > else {<br>
> > // We don't support FMA.<br>
> > setOperationAction(ISD::FMA, MVT::f64, Expand);<br>
> > setOperationAction(ISD::FMA, MVT::f32, Expand);<br>
> > }<br>
><br>
><br>
<br>
</div></div>There are a few conditions that contribute to the decision of whether or not to make the fmuladd -> fma translation. The relevant code is in CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:<br>
<br>
  case Intrinsic::fmuladd: {<br>
    EVT VT = TLI.getValueType(I.getType());<br>
    if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict &&<br>
        TLI.isOperationLegal(ISD::FMA, VT) &&<br>
        TLI.isFMAFasterThanMulAndAdd(VT)){<br>
<br>
       [ use FMA ]<br>
    } else {<br>
       [ use MUL + ADD ]<br>
    }<br>
<br>
 -Hal<br>
<br>
><br>
><br>
> Hope that helps,<br>
> Cameron<br>
<div class="im HOEnZb">><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Postdoctoral Appointee<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>