[LLVMdev] Documentation of fmuladd intrinsic

[Justin Holewinski]

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>