On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <andrew.booker at arm.com>wrote:> The fmuladd intrinsic is described as saying that a multiply and > addition sequence can be fused into an fma instruction "if the code > generator determines that the fused expression would be legal and > efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic) > > I've spent a bit of time puzzling over how a code generator is supposed > to know if it's legal to generate an fma instead of a multiply and add > - surely that's something for the frontend to determine, based on the > FP_CONTRACT setting, and not something for the code generator to work > out? > > However, recently I came across > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582 > 22.html > which explains that "legal" in the above definition doesn't mean legal > from the point of view of the source language, but simply means whether > or not the target architecture has an fma instruction. The thread also > talks about updating the documentation to clarify this, but that > doesn't seem to have happened. > > Assuming that the thread I've linked to is correct, would it be > possible to clarify the IR spec accordingly? I think that the current > use of the word "legal" is misleading. > >Hey Andrew, I believe that the term "legal" is associated with the Legalize phase. Please see: http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase The x86 backend has a good example of this in llvm/lib/Target/X86/X86ISelLowering.cpp:> if (Subtarget->hasFMA()) { > // Support FMAs! > setOperationAction(ISD::FMA, MVT::f64, Legal); > setOperationAction(ISD::FMA, MVT::f32, Legal); > } > else { > // We don't support FMA. > setOperationAction(ISD::FMA, MVT::f64, Expand); > setOperationAction(ISD::FMA, MVT::f32, Expand); > }Hope that helps, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/06575ce6/attachment.html>
----- Original Message -----> From: "Cameron McInally" <cameron.mcinally at nyu.edu> > To: "Andrew Booker" <andrew.booker at arm.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, January 11, 2013 12:37:07 PM > Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic > > > On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker < > andrew.booker at arm.com > wrote: > > > > The fmuladd intrinsic is described as saying that a multiply and > addition sequence can be fused into an fma instruction "if the code > generator determines that the fused expression would be legal and > efficient". ( http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic ) > > I've spent a bit of time puzzling over how a code generator is > supposed > to know if it's legal to generate an fma instead of a multiply and > add > - surely that's something for the frontend to determine, based on the > FP_CONTRACT setting, and not something for the code generator to work > out? > > However, recently I came across > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582 > 22.html > which explains that "legal" in the above definition doesn't mean > legal > from the point of view of the source language, but simply means > whether > or not the target architecture has an fma instruction. The thread > also > talks about updating the documentation to clarify this, but that > doesn't seem to have happened. > > Assuming that the thread I've linked to is correct, would it be > possible to clarify the IR spec accordingly? I think that the current > use of the word "legal" is misleading. > > > > > Hey Andrew, > > > I believe that the term "legal" is associated with the Legalize > phase. Please see: > > > http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase > > > The x86 backend has a good example of this in > llvm/lib/Target/X86/X86ISelLowering.cpp: > > > > > if (Subtarget->hasFMA()) { > > // Support FMAs! > > setOperationAction(ISD::FMA, MVT::f64, Legal); > > setOperationAction(ISD::FMA, MVT::f32, Legal); > > } > > else { > > // We don't support FMA. > > setOperationAction(ISD::FMA, MVT::f64, Expand); > > setOperationAction(ISD::FMA, MVT::f32, Expand); > > } > >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: case Intrinsic::fmuladd: { EVT VT = TLI.getValueType(I.getType()); if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict && TLI.isOperationLegal(ISD::FMA, VT) && TLI.isFMAFasterThanMulAndAdd(VT)){ [ use FMA ] } else { [ use MUL + ADD ] } -Hal> > > Hope that helps, > Cameron > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
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. On Fri, Jan 11, 2013 at 2:40 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Cameron McInally" <cameron.mcinally at nyu.edu> > > To: "Andrew Booker" <andrew.booker at arm.com> > > Cc: llvmdev at cs.uiuc.edu > > Sent: Friday, January 11, 2013 12:37:07 PM > > Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic > > > > > > On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker < > > andrew.booker at arm.com > wrote: > > > > > > > > The fmuladd intrinsic is described as saying that a multiply and > > addition sequence can be fused into an fma instruction "if the code > > generator determines that the fused expression would be legal and > > efficient". ( http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic ) > > > > I've spent a bit of time puzzling over how a code generator is > > supposed > > to know if it's legal to generate an fma instead of a multiply and > > add > > - surely that's something for the frontend to determine, based on the > > FP_CONTRACT setting, and not something for the code generator to work > > out? > > > > However, recently I came across > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582 > > 22.html > > which explains that "legal" in the above definition doesn't mean > > legal > > from the point of view of the source language, but simply means > > whether > > or not the target architecture has an fma instruction. The thread > > also > > talks about updating the documentation to clarify this, but that > > doesn't seem to have happened. > > > > Assuming that the thread I've linked to is correct, would it be > > possible to clarify the IR spec accordingly? I think that the current > > use of the word "legal" is misleading. > > > > > > > > > > Hey Andrew, > > > > > > I believe that the term "legal" is associated with the Legalize > > phase. Please see: > > > > > > http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase > > > > > > The x86 backend has a good example of this in > > llvm/lib/Target/X86/X86ISelLowering.cpp: > > > > > > > > > if (Subtarget->hasFMA()) { > > > // Support FMAs! > > > setOperationAction(ISD::FMA, MVT::f64, Legal); > > > setOperationAction(ISD::FMA, MVT::f32, Legal); > > > } > > > else { > > > // We don't support FMA. > > > setOperationAction(ISD::FMA, MVT::f64, Expand); > > > setOperationAction(ISD::FMA, MVT::f32, Expand); > > > } > > > > > > 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: > > case Intrinsic::fmuladd: { > EVT VT = TLI.getValueType(I.getType()); > if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict && > TLI.isOperationLegal(ISD::FMA, VT) && > TLI.isFMAFasterThanMulAndAdd(VT)){ > > [ use FMA ] > } else { > [ use MUL + ADD ] > } > > -Hal > > > > > > > Hope that helps, > > Cameron > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/348443a9/attachment.html>
Hal Finkel <hfinkel at anl.gov> writes:> 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: > > case Intrinsic::fmuladd: { > EVT VT = TLI.getValueType(I.getType()); > if (TM.Options.AllowFPOpFusion != FPOpFusion::Strict && > TLI.isOperationLegal(ISD::FMA, VT) && > TLI.isFMAFasterThanMulAndAdd(VT)){ > > [ use FMA ] > } else { > [ use MUL + ADD ] > }We've written a few TableGen patterns here locally to match FMA and added a predicate to say in effect TM.Options.AllowFPOpFusion !FPOpFusion::Strict. So that's another way to proceed. In general, I prefer TableGen patterns over manual lowering. -David