search for: sdnodeflags

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 = (Options.AllowFPOpFusion == FPOpFusion::Fast || CanFuse || HasFMAD); // If the addition is not contractable, do not combine. if (...

...; 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 = (Options.AllowFPOpFusion == > FPOpFusion::Fast || CanFuse || HasFMAD); >...

Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +

...that we need/want to support? > > I'm asking because FMF in IR is currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can share the > struct with the backend's SDNodeFlags, but that already has one extra > bit for vector reduction. Should we give up on SubclassOptionalData > for FMF? We have a MD_fpmath enum value for metadata, so we could move > things over there? I agree that using SubclassOptionalData is going to be problematic when we run out of bit...

...gt; > >     // 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 = (Options.AllowFPOpFusion == >...

...nt all of the relaxed FP states that we need/want to support? I'm asking because FMF in IR is currently mapped onto the SubclassOptionalData of Value...and we have exactly 7 bits there. :) If we're redoing the definitions, I'm wondering if we can share the struct with the backend's SDNodeFlags, but that already has one extra bit for vector reduction. Should we give up on SubclassOptionalData for FMF? We have a MD_fpmath enum value for metadata, so we could move things over there? On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-...

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

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

...ss, we can add a flag indicating if the phi node is a reduction one (the flag can be set in loop vectorizer for vectorized phi nodes). Then when we build SDNode for instruction selection, we detect those reduction phi nodes and then annotate reduction operations. This requires an additional flag in SDNodeFlags. We can then check this flag when combining instructions to detect reduction operations. In this approach, I have managed to let LLVM compile a SAD loop into psadbw instructions. Source code: const int N = 1024; unsigned char a[N], b[N]; int sad() { int s = 0; for (int i = 0; i < N; ++i...

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

...tps://llvm.org/bugs/show_bug.cgi?id=13118 > 3. The backend needs a thread of its own. We have at least these > mechanisms to handle FMA codegen: > a. TargetOptions for LessPreciseFPMADOption, UnsafeFPMath, > NoInfsFPMath, NoNaNsFPMath, AllowFPOpFusion (Fast, Standard, Strict) > b. SDNodeFlags for UnsafeAlgebra, NoNaNs, NoInfs, NoSignedZeros (but > nothing for FMA since IR FMF has nothing for FMA) > c. SelectionDAGTargetInfo::generateFMAsInMachineCombiner() > d. TargetLoweringBase::isFMAFasterThanFMulAndFAdd() > e. TargetLoweringBase::enableAggressiveFMAFusion() > f. I...

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

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

...ode is a reduction one (the flag >> can >> be set in loop vectorizer for vectorized phi nodes). Then when we >> build SDNode for instruction selection, we detect those reduction phi >> nodes and then annotate reduction operations. This requires an >> additional flag in SDNodeFlags. We can then check this flag when >> combining instructions to detect reduction operations. >> >> In this approach, I have managed to let LLVM compile a SAD loop into >> psadbw instructions. >> >> Source code: >> >> >> const int N = 1024; >&g...

Sent from my Verizon Wireless 4G LTE DROID On Nov 17, 2016 5:53 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Nov 17, 2016, at 4:33 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Warren

...lOperations && >>>> > TLI.isOperationLegal(ISD::FMAD, VT)); >>>> > >>>> > static bool isContractable(SDNode *N) { >>>> > SDNodeFlags F = N->getFlags(); >>>> > return F.hasAllowContract() || >>>> F.hasAllowReassociation(); >>>> > } >>>> > >>>>...

...gt;> can > >> be set in loop vectorizer for vectorized phi nodes). Then when we > >> build SDNode for instruction selection, we detect those reduction > >> phi > >> nodes and then annotate reduction operations. This requires an > >> additional flag in SDNodeFlags. We can then check this flag when > >> combining instructions to detect reduction operations. > >> > >> In this approach, I have managed to let LLVM compile a SAD loop > >> into > >> psadbw instructions. > >> > >> Source code: > &g...

...want to support? > > I'm asking because FMF in IR is currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can share > the struct with the backend's SDNodeFlags, but that already has > one extra bit for vector reduction. Should we give up on > SubclassOptionalData for FMF? We have a MD_fpmath enum value for > metadata, so we could move things over there? > > On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev >...

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' +