search for: reassoc

...t the responsibility on > front ends to mint the proper expression level flags to control the desired > behavior. > > Regards, > Michael > > On Aug 23, 2018, at 12:13 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Michael, > > From the spec with regards to reassoc: > > – 15225 Include no re-association as a constraint required by the > NoContraction Decoration. > > I don't see a solution given the situation where -fp-contract=fast and we > want to contract. Furthermore, I think a 'nocontract' flag will allow the > IR to be...

Michael, >From the spec with regards to reassoc: – 15225 Include no re-association as a constraint required by the NoContraction Decoration. I don't see a solution given the situation where -fp-contract=fast and we want to contract. Furthermore, I think a 'nocontract' flag will allow the IR to be more readable in it's intenti...

...ith SPIR-V here. Something along the lines of (in LangRef): ``contract`` Allow floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-and-add). This flag must be present on all affected instruction. And we should probably say the same about ``reassoc`` as well. Cheers, Nicolai > > On Wed, Aug 22, 2018 at 3:55 AM Nicolai Hähnle via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > > So I have a test case w...

...ect behavior though in your SPIR-V implementation wrt IR flag emissions. Regards, Michael > On Aug 23, 2018, at 1:35 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > I think what Michael is saying that: > > 1. Don't set the global flag. > 2. Set `contract` and `reassoc` on *all* floating point instructions by default. > 3. Don't set those flags on instructions with NoContraction in SPIR-V. > > I agree with the general thrust of this approach, except for the significant problem that it currently doesn't work. > > If we follow 1-3 above, th...

...inverse flag > system to what we have in IR and DAG - ops are presumed contract-able > unless specified with 'no-contract'? Not sure how to resolve that. > > If we want to change the LLVM FMF semantics, then there will be breakage > in the IR optimizer too (at least for 'reassoc'; not sure about > 'contract'). Either way, I agree that we should try to clarify the LangRef > about this because you can't tell how things are supposed to work from the > current description. > > > On Wed, Aug 22, 2018 at 9:41 AM, Nicolai Hähnle via llvm-dev <...

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

...s 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 (!AllowFusionGlobally && !isContractable(N)) return SDValue();...

...``contract`` >     Allow floating-point contraction (e.g. fusing a multiply > followed by >     an addition into a fused multiply-and-add). This flag must be > present >     on all affected instruction. > > And we should probably say the same about ``reassoc`` as well. > > Cheers, > Nicolai > > > > > > > > On Wed, Aug 22, 2018 at 3:55 AM Nicolai Hähnle via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > <mailto:llvm-dev at lists.llvm.org...

> 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

...der fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively represented: UnsafeMath nnan ninf nsz arcp contract *unset* (The order may not match what is exactly in the bitcode.) After r317488 we had 7 bits that respectively represented: reassoc (-UnsafeMath- is gone) nnan ninf nsz arcp contract *afn* (new bit) Before r317488, fast-math was true if UnsafeMath was true (this should also imply all the other flags are sets). After r317488, fast-math is true if all the bits are set, in particular the afn, new one, too. * Problem * Given we...

For this code: %20 = fmul reassoc nnan arcp contract float %15, %19 %21 = fadd nnan arcp float %20, -1.000000e+00 This does not result in fused multiply-add. it seems like the logic to contact the fmul from the fadd is different than whether to decide to contract the fadd. I would think the logic would be the same for each inst...

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

...s: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Before r317488, fast-math was true if UnsafeMath was true (this should also imply all the other flags are sets). After r317488, fast-math is true if all the bits are set, in particular the af...

...ce.v2.fadd.f32.v4f32(float %start_value, <4 x float> %vec) This means that if the start value is 'undef', the result will be undef and all code creating such a reduction will need to ensure it has a sensible start value (e.g. 0.0 for fadd, 1.0 for fmul). When using 'fast' or ‘reassoc’ on the call it will be implemented using an unordered reduction, otherwise it will be implemented with an ordered reduction. Note that a new intrinsic is required to capture the new semantics. In this proposal the intrinsic is prefixed with a 'v2' for the time being, with the expectation t...

...> > In my case I'm talking about allowing the use of lower precision but very fast machine > instructions instead of a slow sequence of inline instructions. But I guess instruction > vs library is equivalent. I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when y...

...> > In my case I'm talking about allowing the use of lower precision but very fast machine > instructions instead of a slow sequence of inline instructions. But I guess instruction > vs library is equivalent. I haven't defined "libm" explicitly. The concept of "reassoc" and "libm" are a result of the discussion last November. The "libm" aspect in particular, came from: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107114.html It was intended to mean actual library functions, which is what I thought you were referring to when y...

...this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Before r317488, fast-math was true if UnsafeMath was true (this should > also imply all the other flags are sets). After r317488, fast-math is true > if all the bits are set, in particul...

...this: > Before r317488 we had 6 bits that respectively represented: > > UnsafeMath > nnan > ninf > nsz > arcp > contract > *unset* > > (The order may not match what is exactly in the bitcode.) > > After r317488 we had 7 bits that respectively represented: > reassoc (-UnsafeMath- is gone) > nnan > ninf > nsz > arcp > contract > *afn* (new bit) > > Before r317488, fast-math was true if UnsafeMath was true (this should > also imply all the other flags are sets). After r317488, fast-math is true > if all the bits are set, in particul...

...x float> %vec) >> >> This means that if the start value is 'undef', the result will be >> undef and all code creating such a reduction will need to ensure it >> has a sensible start value (e.g. 0.0 for fadd, 1.0 for fmul). When >> using 'fast' or ‘reassoc’ on the call it will be implemented using an >> unordered reduction, otherwise it will be implemented with an ordered >> reduction. Note that a new intrinsic is required to capture the new >> semantics. In this proposal the intrinsic is prefixed with a 'v2' for >&gt...

...gt;> 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' + 'arcp' + 'contract' >> >> would be more useful. Related to this, the current 'fast' flag which acts >> as an umbrella (enabling 'nnan' + 'ninf' + 'nsz' + '...