search for: fmuladds

A little background: The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I

Hi, I would like to add an ISD node for an fmad operation (named either FMAD or FMULADD). It will have the semantics of returning the same result as the separate multiply and add with the intermediate rounding step, and not a differently rounded result. The motivation is to share code with the various FMA forming DAG combines, but will be generally more useful on targets that support it

Thanks for all the replies - it pretty much confirmed what I think I'd worked out about how fmuladd is supposed to behave. But my initial query wasn't asking what fmuladd did - it was asking for the documentation about it to be clarified. Can I suggest that the Overview section for fmuladd is changed to say the following (the key point being the removal of the word "legal" in

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

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 !=

----- Original Message ----- > From: "Justin Holewinski" <justin.holewinski at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "David A. Greene" <dag at cray.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 11, 2013 2:19:01 PM > Subject: Re: [LLVMdev] Documentation of

Hi, Eli, Mike and Lang: Thank you all for the input. This is one e.g which might be difficult for isel: a*b + c*d + e => a*b + (c*d + e). Thanks Shuxin On 12/12/12 4:43 PM, Lang Hames wrote: > A little background: > > The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma > in C. llvm.fmuladd.* is generated by clang when it sees an expression > of the

On Fri, Jan 11, 2013 at 3:16 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: dag at cray.com > > To: "Justin Holewinski" <justin.holewinski at gmail.com> > > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Developers Mailing List" < > llvmdev at cs.uiuc.edu> > > Sent: Friday,

----- 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 < >

----- Original Message ----- > From: dag at cray.com > To: "Justin Holewinski" <justin.holewinski at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 11, 2013 2:13:50 PM > Subject: Re: [LLVMdev] Documentation of fmuladd intrinsic > > Justin

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

On Dec 12, 2012, at 3:40 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Dear All: > > I'm going implement FMA formation. On some architectures, "FMA a, b, c" is more precise than > "a * b + c". I'm wondering if FMA could be less precise. In the former case, can we enable FMA > formation despite restrictive FP mode? > I believe

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) > >

We have a function that has 256 loads and 256 fmuladds. This block of operations is bounded at either end by an OpenCL barrier (an AMDIL fence instruction). The loads and multiply/adds are ordinarily interleaved... that is, the IR going in to code generation looks like: %39 = load float addrspace(3)* getelementptr inbounds ([16 x [17 x float]] addrsp...

Hi, Dear All: I'm going implement FMA formation. On some architectures, "FMA a, b, c" is more precise than "a * b + c". I'm wondering if FMA could be less precise. In the former case, can we enable FMA formation despite restrictive FP mode? Thanks Shuxin

Sent from my Verizon Wireless 4G LTE DROID On Nov 19, 2016 10:26 AM, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: > > If I have my FMA intrinsics story straight now (thanks for the explanation, Hal!), I think it raises another question about IR canonicalization (and may affect the proposed revision to IR FMF): No, I think that we specifically

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: > -----

The potential advantage I was considering would be more accurate cost modeling in the vectorizer, inliner, etc. Like min/max, this is another case where the sum of the IR parts is greater than the actual cost. Beyond that, it seems odd to me that we'd choose the longer IR expression of something that could be represented in a minimal form. I know we make practical concessions in IR based on

Justin Holewinski <justin.holewinski at gmail.com> writes: > 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 Dec 12, 2012, at 4:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Eli, Mike and Lang: > > Thank you all for the input. This is one e.g which might be difficult for isel: > a*b + c*d + e => a*b + (c*d + e). > You hit send right when I did! For your example, do you mean that it's grouped like: (fadd (fadd (fmul a b) (fmul c d)) e) How would your