similar to: [LLVMdev] Question about FMA formation

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

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

Right now we're shying towards having a re-association helper in codegen-prepare that will re-associate expressions (if allowed). This would allow fast-isel to more easily spot FMA opportunities, and form better code. On Dec 12, 2012, at 5:11 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > You hit send right when I did! > For your example, do you mean that

Why not just form them via a fast IR level pass and just have patterns match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass). -eric On Wed, Dec 12, 2012 at 5:14 PM, Michael Ilseman <milseman at apple.com>

On Dec 12, 2012, at 5:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Why not just form them via a fast IR level pass and just have patterns match in fast isel instead of trying to form code? Or are we saying the same thing? (Your words of "fast isel spot"ting and "form better code" caused me to think you mean to do optimizations within the fast isel pass).

Hi Michael, Shuxin, > Shuxin was showing some more complicated patterns that required > re-association to match (fast-math flags permitting). For those, we're > considering if having a re-associate-for-FMA functionality in > codegen-prepare would solve that problem. Thus, we can re-associate in > codegen-prepare and emit FMA in fast-isel. > Yep. I misread the association

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

Thanks! That’s probably close enough for practical purposes. I looked at the overrides on various targets, and they all return true if the FMA hardware exists. - Arch From: Jingyue Wu [mailto:jingyue at google.com] Sent: Wednesday, December 10, 2014 2:56 PM To: Robison, Arch Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Best way for JIT to query whether llvm.fma.* is fast? Does

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

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

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 pass go about handling these patterns and is that something > that would be too complicated for fast-isel to do on the fly? > > Depends on how they're grouped, but if the formation happens prior to codegen then fast-isel will

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

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

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

----- Original Message ----- > From: "Sanjay Patel" <spatel at rotateright.com> > To: "Hal J. Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, > "andrew kaylor" <andrew.kaylor at

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,