[LLVMdev] Documentation of fmuladd intrinsic

[Hal Finkel]

----- Original Message -----
> From: dag at cray.com
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "cameron mcinally" <cameron.mcinally at nyu.edu>, llvmdev at cs.uiuc.edu
> Sent: Friday, January 11, 2013 2:12:01 PM
> Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic
> 
> 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.

Just to be clear, fmuladd was really only added for one reason: to allow the proper modeling of fp-contraction restrictions in the C99 standard. Because these restrictions are based on source-language statement boundaries, and statement boundaries are known only to the frontend, we needed a way for the frontend to create fmas that could later be undone in a target-specific way.

 -Hal

> 
>                                -David
> 

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