search for: fmad

I'm curious why the condition to fuse is this: // Floating-point multiply-add with intermediate rounding. bool HasFMAD = (LegalOperations && TLI.isOperationLegal(ISD::FMAD, VT)); static bool isContractable(SDNode *N) { SDNodeFlags F = N->getFlags(); return F.hasAllowContract() || F.hasAllowReassociation(); } bool CanFuse = Options.UnsafeFPMath || isContractable(N); bool AllowFusionGlobally = (Optio...

...arithmetic instruction I think that makes sense, but the end result is the same. Wouldn't you agree that -fp-contract=off still contracts floating point expressions with the initial example I posted? That is the core of what I'm trying to resolve here. I still have some confusion of what FMAD is supposed to be. Is FMAD actually MAD? Or is it something else? I am fine with leaving it alone if FMAD is not actually contracting floating point operations. On Fri, Jul 12, 2019 at 10:54 AM Stephen Canon <scanon at apple.com> wrote: > Echoing what everyone else has said, keying on th...

> On Aug 21, 2018, at 17:08, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has no reassoc or contract fast math flag? > > Thanks. fmad is defined as the exact same result as the separate fmul + fadd, unlike fma so this is OK -Matt

...Clang option suggests this to be the case: $ clang --help | grep fp-contract -ffp-contract=<value> Form fused FP ops (e.g. FMAs): fast (everywhere) | on (according to FP_CONTRACT pragma, default) | off (never fuse) Current behaviour in LLVM 8.0 below: $ cat fma.ll define double @fmadd(double %a, double %b, double %c) { %mul = fmul fast double %b, %a %add = fadd fast double %mul, %c ret double %add } $ llc -mattr=+fma fma.ll -fp-contract=off -o - | grep vfmadd vfmadd213sd %xmm2, %xmm1, %xmm0 # xmm0 = (xmm1 * xmm0) + xmm2 It still generates an fma due to the logic i...

On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has > no reassoc or contract fast math flag? By having the reassoc and contract flags on fadd, the frontend is essentially saying "different rounding on the value produced by the fadd is okay". So I'd say contracting this to fma is correct. Whe...

Numerically identical, sure. But, there are other reasons to disable FMAD fusion -- namely for performance comparisons. On Wed, Jul 10, 2019 at 2:52 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Jul 10, 2019, at 15:27, Scott Manley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Is there context I am not aware of for ::S...

> On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Matt, > I'm sorry, actually it's fma not fmad. > > In the post-legalizer DAG combine for the given code it's producing fma not fmad. That doens't seem correct. > The contract is on the fadd. I’m not really sure what the rule is supposed to be for contract between the nodes. The LangRef doesn’t clarify on this. I would assum...

...n 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > > So I have a test case where: > > > > %20 = fmul nnan arcp float %15, %19 > > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > > > is being contracted in DAG to fmad. Is this correct since the > fmul has > > no reassoc or contract fast math flag? > > By having the reassoc and contract flags on fadd, the frontend is > essentially saying "different rounding on the value produced by the > fadd > is okay"....

...tthew.Arsenault at amd.com> >> To: "llvmdev at cs.uiuc.edu" <LLVMdev at cs.uiuc.edu> >> Sent: Wednesday, January 28, 2015 1:52:59 PM >> Subject: [LLVMdev] RFC: Add ISD nodes for mad >> >> 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 >&g...

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

..., 2019, at 16:56, Scott Manley <rscottmanley at gmail.com> wrote: > > At any rate, I was only offering an additional reason. Personally I think > it's strange for an option to say "this will never fuse ops" and then under > the covers will fuse ops, regardless of how FMAD is defined. However, my > primary concern is for FMAs. They have both numeric and performance > implications and I do not think it's unreasonable that off means off. > > > I think you have a different definition of fused then. Fused is a > description of how the operation is c...

...amount or setting the preferred vector width or many other options in both clang and llvm? At any rate, I was only offering an additional reason. Personally I think it's strange for an option to say "this will never fuse ops" and then under the covers will fuse ops, regardless of how FMAD is defined. However, my primary concern is for FMAs. They have both numeric and performance implications and I do not think it's unreasonable that off means off. On Wed, Jul 10, 2019 at 3:36 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Wed, 10 Jul 2019 at 21:09, Scott Ma...

...>      > So I have a test case where: > >      > > >      > %20 = fmul nnan arcp float %15, %19 > >      > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > >      > > >      > is being contracted in DAG to fmad. Is this correct since the > >     fmul has > >      > no reassoc or contract fast math flag? > > > >     By having the reassoc and contract flags on fadd, the frontend is > >     essentially saying "different rounding on the value prod...

...gt; > > On Tue, Aug 21, 2018 at 11:04 AM Matt Arsenault <arsenm2 at gmail.com> wrote: > >> >> >> > On Aug 21, 2018, at 17:57, Ryan Taylor <ryta1203 at gmail.com> wrote: >> > >> > Matt, >> > I'm sorry, actually it's fma not fmad. >> > >> > In the post-legalizer DAG combine for the given code it's producing fma >> not fmad. That doens't seem correct. >> > >> >> The contract is on the fadd. I’m not really sure what the rule is >> supposed to be for contract between t...

...te: >>> > So I have a test case where: >>> > >>> > %20 = fmul nnan arcp float %15, %19 >>> > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 >>> > >>> > is being contracted in DAG to fmad. Is this correct since the >>> fmul has >>> > no reassoc or contract fast math flag? >>> >>> By having the reassoc and contract flags on fadd, the frontend is >>> essentially saying "different rounding on the value produced by th...

...> So I have a test case where: >>>> > >>>> > %20 = fmul nnan arcp float %15, %19 >>>> > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 >>>> > >>>> > is being contracted in DAG to fmad. Is this correct since the >>>> fmul has >>>> > no reassoc or contract fast math flag? >>>> >>>> By having the reassoc and contract flags on fadd, the frontend is >>>> essentially saying "different rounding on the...

...est case where: >>>>> > >>>>> > %20 = fmul nnan arcp float %15, %19 >>>>> > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 >>>>> > >>>>> > is being contracted in DAG to fmad. Is this correct since the >>>>> fmul has >>>>> > no reassoc or contract fast math flag? >>>>> >>>>> By having the reassoc and contract flags on fadd, the frontend is >>>>> essentially saying "differ...

...= fmul nnan arcp float %15, %19 >>>> > %21 = fadd reassoc nnan arcp contract >>>> float %20, -1.000000e+00 >>>> > >>>> > is being contracted in DAG to fmad. Is >>>> this correct since the >>>> fmul has >>>> > no reassoc or contract fast math flag? >>>> >>>> By having the reassoc and contract flags on...

...-dev < cfe-dev at lists.llvm.org> wrote: > > > On Sep 16, 2019, at 19:57, Kaylor, Andrew via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Do we need an ftz fast-math flag? > > > This would be useful for matching a handful of AMDGPU instructions (a fmad > that only always flushes being the most important). We have a dedicated > intrinsic to allow flushing in this case when denormals are enabled > +1 For FTZ/DAZ, we're currently getting cases like this incorrect: %add = fadd nnan ninf nsz float %a, 0.000000e+00 That cannot be saf...

Op 11-01-15 om 01:34 schreef Ilia Mirkin: > And you're allowing saturate/neg emission on the short form. Yes > Is this already in envytools? Tesla floating point instructions are poorly documented in the RST documents; fmad is no exception. I'll make sure to check envydis. > Also, what's the shortForm thing? Documented in envytools; see http://envytools.readthedocs.org/en/latest/hw/graph/tesla/cuda/isa.html#instruction-format . In short, opcodes are either 4 bytes (short) or 8 bytes (long). > This chan...