<div dir="ltr"><div>I'm not sure how prevalent it is, but it definitely occurs because the Flags parameter is optional. <br></div><div><br></div><div>As with the IR equivalent, it should always be correct (not a miscompile) to silently drop the flags, but that can prevent optimizations as with the case you're looking at.</div><div><br></div><div>I'm not aware of any dedicated effort to fix these, but patches are welcome. The usual fix is to propagate or intersect flags from existing nodes. <br></div><div><br></div><div>Alive2 has been good at spotting miscompiles from wrongly propagating flags in IR. So if you can create an IR-equivalent test, then you could use Alive2 to confirm correctness. Sadly, the online version of the app seems to be timing out today:</div><div><a href="http://volta.cs.utah.edu:8080/" target="_blank">http://volta.cs.utah.edu:8080/</a>
</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 13, 2020 at 1:19 PM Nemanja Ivanovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>While fixing something, I discovered that the DAG combiner will drop the flags from ISD::FMAXNUM if it is swapping operands to canonicalize the constant operand on the RHS. <br></div><div>That is presumably because of this code in the DAG combiner:</div><div><span style="font-family:monospace">  // Canonicalize to constant on RHS.<br>  if (isConstantFPBuildVectorOrConstantFP(N0) &&<br>      !isConstantFPBuildVectorOrConstantFP(N1))<br>    return DAG.getNode(N->getOpcode(), SDLoc(N), VT, N1, N0);</span></div><div><br></div><div>As a result, the DAG transformations that are applied to something like</div><div><span style="font-family:monospace"><span>call</span> <span>fast</span> <span><</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>@llvm.maxnum.v4f32</span><span>(<</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>%3</span><span>,</span> <span><</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>zeroinitializer</span><span>)</span></span></div><div><span>vs.</span></div><div><span style="font-family:monospace"><span><span>call</span> <span>fast</span> <span><</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>@llvm.maxnum.v4f32</span><span>(<</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>zeroinitializer</span><span>,</span> <span><</span><span>4</span> <span>x</span> <span>float</span><span>></span> <span>%3</span><span>)</span></span></span><br></div><div>will be very different.</div><div><br></div><div>I wanted to get some opinions on how prevalent this is and whether there is any effort ongoing to fix it.<br></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>