<div dir="ltr">Just a quick change of isContractableFMUL to isContractable gives about 49 unexpected failures.<div><br></div><div><div>********************</div><div>Testing Time: 391.60s</div><div>********************</div><div>Failing Tests (49):</div><div> LLVM :: CodeGen/AArch64/neon-fma-FMF.ll</div><div> LLVM :: CodeGen/AMDGPU/clamp-modifier.ll</div><div> LLVM :: CodeGen/AMDGPU/fadd-fma-fmul-combine.ll</div><div> LLVM :: CodeGen/AMDGPU/fcanonicalize-elimination.ll</div><div> LLVM :: CodeGen/AMDGPU/fma-combine.ll</div><div> LLVM :: CodeGen/AMDGPU/fmad.ll</div><div> LLVM :: CodeGen/AMDGPU/fmul-2-combine-multi-use.ll</div><div> LLVM :: CodeGen/AMDGPU/fmuladd.f16.ll</div><div> LLVM :: CodeGen/AMDGPU/fmuladd.f32.ll</div><div> LLVM :: CodeGen/AMDGPU/fmuladd.f64.ll</div><div> LLVM :: CodeGen/AMDGPU/fneg-combines.ll</div><div> LLVM :: CodeGen/AMDGPU/fpext-free.ll</div><div> LLVM :: CodeGen/AMDGPU/llvm.cos.ll</div><div> LLVM :: CodeGen/AMDGPU/llvm.fmuladd.f16.ll</div><div> LLVM :: CodeGen/AMDGPU/llvm.sin.ll</div><div> LLVM :: CodeGen/AMDGPU/mad-combine.ll</div><div> LLVM :: CodeGen/AMDGPU/mad-mix-hi.ll</div><div> LLVM :: CodeGen/AMDGPU/mad-mix-lo.ll</div><div> LLVM :: CodeGen/AMDGPU/mad-mix.ll</div><div> LLVM :: CodeGen/AMDGPU/madak.ll</div><div> LLVM :: CodeGen/AMDGPU/madmk.ll</div><div> LLVM :: CodeGen/AMDGPU/omod.ll</div><div> LLVM :: CodeGen/AMDGPU/operand-folding.ll</div><div> LLVM :: CodeGen/AMDGPU/pv-packing.ll</div><div> LLVM :: CodeGen/AMDGPU/reduction.ll</div><div> LLVM :: CodeGen/AMDGPU/sdwa-peephole.ll</div><div> LLVM :: CodeGen/AMDGPU/shared-op-cycle.ll</div><div> LLVM :: CodeGen/AMDGPU/v_mac.ll</div><div> LLVM :: CodeGen/AMDGPU/v_mac_f16.ll</div><div> LLVM :: CodeGen/AMDGPU/v_madak_f16.ll</div><div> LLVM :: CodeGen/Hexagon/float-amode.ll</div><div> LLVM :: CodeGen/Hexagon/fmadd.ll</div><div> LLVM :: CodeGen/Hexagon/fp_latency.ll</div><div> LLVM :: CodeGen/NVPTX/fma-assoc.ll</div><div> LLVM :: CodeGen/PowerPC/a2-fp-basic.ll</div><div> LLVM :: CodeGen/PowerPC/fma-aggr-FMF.ll</div><div> LLVM :: CodeGen/PowerPC/fma-assoc.ll</div><div> LLVM :: CodeGen/PowerPC/fma-ext.ll</div><div> LLVM :: CodeGen/PowerPC/fma.ll</div><div> LLVM :: CodeGen/PowerPC/fmf-propagation.ll</div><div> LLVM :: CodeGen/PowerPC/ppc440-fp-basic.ll</div><div> LLVM :: CodeGen/PowerPC/qpx-recipest.ll</div><div> LLVM :: CodeGen/PowerPC/recipest.ll</div><div> LLVM :: CodeGen/X86/avx512-fma.ll</div><div> LLVM :: CodeGen/X86/fma-do-not-commute.ll</div><div> LLVM :: CodeGen/X86/fma_patterns.ll</div><div> LLVM :: CodeGen/X86/fma_patterns_wide.ll</div><div> LLVM :: CodeGen/X86/sqrt-fastmath-mir.ll</div><div> LLVM :: CodeGen/X86/sqrt-fastmath.ll</div><div><br></div><div> Expected Passes : 25605</div><div> Expected Failures : 149</div><div> Unsupported Tests : 676</div><div> Unexpected Failures: 49</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 22, 2018 at 4:33 PM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 22.08.2018 17:52, Ryan Taylor wrote:<br>
> This is probably going to effect on other backends and break llvm-lit <br>
> for them?<br>
<br>
Very likely, yes. Can you take a look at how big the fallout is? This <br>
might give us a hint about what other frontends might expect, and who <br>
needs to be involved in the discussion (if one is needed).<br>
<br>
Cheers,<br>
Nicolai<br>
<br>
<br>
> <br>
> On Wed, Aug 22, 2018 at 11:41 AM Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a> <br>
> <mailto:<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>>> wrote:<br>
> <br>
> On 22.08.2018 13:29, Ryan Taylor wrote:<br>
> > The example starts as SPIR-V with the NoContraction decoration<br>
> flag on<br>
> > the fmul.<br>
> ><br>
> > I think what you are saying seems valid in that if the user had<br>
> put the<br>
> > flag on the fadd instead of the fmul it would not contract and so in<br>
> > this example the user needs to put the NoContraction on the fadd<br>
> though<br>
> > I'm not sure that's a good expectation of the user. On the<br>
> surface, I<br>
> > think that if an operation didn't have the contract flag than it<br>
> > wouldn't be contracted, regardless of what flags any other<br>
> operation has.<br>
> <br>
> Okay, I see that the SPIR-V spec specifically calls out this example.<br>
> <br>
> Unless there are conflicting requirements with another frontend, I'd<br>
> say<br>
> we should make sure LLVM is aligned with SPIR-V here. Something along<br>
> the lines of (in LangRef):<br>
> <br>
> ``contract``<br>
> Allow floating-point contraction (e.g. fusing a multiply<br>
> followed by<br>
> an addition into a fused multiply-and-add). This flag must be<br>
> present<br>
> on all affected instruction.<br>
> <br>
> And we should probably say the same about ``reassoc`` as well.<br>
> <br>
> Cheers,<br>
> Nicolai<br>
> <br>
> <br>
> <br>
> <br>
> ><br>
> > On Wed, Aug 22, 2018 at 3:55 AM Nicolai Hähnle via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>><br>
> wrote:<br>
> ><br>
> > On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote:<br>
> > > So I have a test case where:<br>
> > ><br>
> > > %20 = fmul nnan arcp float %15, %19<br>
> > > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00<br>
> > ><br>
> > > is being contracted in DAG to fmad. Is this correct since the<br>
> > fmul has<br>
> > > no reassoc or contract fast math flag?<br>
> ><br>
> > By having the reassoc and contract flags on fadd, the frontend is<br>
> > essentially saying "different rounding on the value produced<br>
> by the<br>
> > fadd<br>
> > is okay".<br>
> ><br>
> > So I'd say contracting this to fma is correct.<br>
> ><br>
> > Where does this code come from, and why do you think<br>
> contracting to fma<br>
> > is wrong?<br>
> ><br>
> > Cheers,<br>
> > Nicolai<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ><br>
> > > Thanks.<br>
> > ><br>
> > > On Mon, Aug 20, 2018 at 12:56 PM Ryan Taylor<br>
> <<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a> <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>><br>
> > <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a> <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>>><br>
> > > <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a> <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>><br>
> <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a> <mailto:<a href="mailto:ryta1203@gmail.com" target="_blank">ryta1203@gmail.com</a>>>>> wrote:<br>
> > ><br>
> > > I'm curious why the condition to fuse is this:<br>
> > ><br>
> > > // Floating-point multiply-add with intermediate rounding.<br>
> > > bool HasFMAD = (LegalOperations &&<br>
> > > TLI.isOperationLegal(ISD::FMAD, VT));<br>
> > ><br>
> > > static bool isContractable(SDNode *N) {<br>
> > > SDNodeFlags F = N->getFlags();<br>
> > > return F.hasAllowContract() ||<br>
> F.hasAllowReassociation();<br>
> > > }<br>
> > ><br>
> > > bool CanFuse = Options.UnsafeFPMath || isContractable(N);<br>
> > > bool AllowFusionGlobally = (Options.AllowFPOpFusion ==<br>
> > > FPOpFusion::Fast || CanFuse || HasFMAD);<br>
> > > // If the addition is not contractable, do not combine.<br>
> > > if (!AllowFusionGlobally && !isContractable(N))<br>
> > > return SDValue();<br>
> > ><br>
> > > Specifically the AllowFusionGlobally, I would have<br>
> expected<br>
> > > something more like:<br>
> > ><br>
> > > bool AllowFusionGlobally = (Options.AllowFPOpFusion ==<br>
> > > FPOpFusion::Fast && CanFuse && HasFMAD);<br>
> > ><br>
> > > or at the very least:<br>
> > ><br>
> > > bool AllowFusionGlobally = ((Options.AllowFPOpFusion ==<br>
> > > FPOpFusion::Fast || CanFuse) && HasFMAD);<br>
> > ><br>
> > > It seems that as long as the target can do fmad it<br>
> does do fmad<br>
> > > since HasFMAD is true.<br>
> > ><br>
> > > Thanks.<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > LLVM Developers mailing list<br>
> > > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> > ><br>
> ><br>
> ><br>
> > --<br>
> > Lerne, wie die Welt wirklich ist,<br>
> > Aber vergiss niemals, wie sie sein sollte.<br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> ><br>
> <br>
> <br>
> -- <br>
> Lerne, wie die Welt wirklich ist,<br>
> Aber vergiss niemals, wie sie sein sollte.<br>
> <br>
<br>
<br>
-- <br>
Lerne, wie die Welt wirklich ist,<br>
Aber vergiss niemals, wie sie sein sollte.<br>
</blockquote></div>