similar to: [LLVMdev] getNodePriority()

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

On 08/11/14 07:32 PM, Das, Dibyendu wrote: > Storing llvm-ir in the fat binary may have the same performance issues mentioned below. The fat binary discussed in the proposal has provision for storing the isa/llvm-ir. My point is instead of llvm-ir it shd be something like spir. Ok - so lets see some data. #1 Benchmarks showing at least SPIR dgemm/sgemm performance #2 Some logical explanation

Hi all, The AllowFPOpFusion option passed to a target can currently take 3 different values, Fast, Standard or Strict (TargetOptions.h), being Standard the default. In the DAGCombiner, during the combination of mul and add/subtract into multiply-and-add/subtract, this option is expected to be Fast in order to enable the combine. This means, that by default no multiply-and-add opcodes are going

System details: -------------- Sun Blade 1000, Solaris 8, Sun ONE Compiler Suite (rebranded Forte 7), R versions 1.6.0 and 1.6.2 - suspect others are affected, too Problem description: ------------------- Using the recommended env var setting from p.15 of the Admin Guide, the configure script fails the sgemm sunperf test, even though the sunperf libraries are available Not linking with