<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The “unsafe FP math” transforms aren’t enough; the problem is that even the *safe-math* transforms need to propagate flags from their source nodes, or you end up with un-CSEable duplicates (and of course, lose flags for future transformations!). You need to pass flags in for *every single creation of an FADD, FSUB, FADD, or FDIV*, as far as I can tell. This involves a huge amount of diffs that look like this:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> // fold (fneg (fsub A, B)) -> (fsub B, A)</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""> return DAG.getNode(ISD::FSUB, SDLoc(Op), Op.getValueType(),</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(195, 55, 32);" class="">- Op.getOperand(1), Op.getOperand(0));</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);" class="">+ Op.getOperand(1), Op.getOperand(0),</div><div style="margin: 0px; font-size: 11px; font-family: Menlo; color: rgb(52, 189, 38);" class="">+ &cast<BinaryWithFlagsSDNode>(Op)->Flags);</div></div><div class=""><br class=""></div><div class="">One idea I had was to allow conservative CSE. That is, allow CSEing nodes with fast-math flags, even if their flags differ — just, when CSEing them, pick the intersection of the two flags. This will guarantee that CSE will still function, even if DAG folds don’t properly maintain fast-math flags. But we still need to eventually add all these flag propagations; otherwise having fast-math flags in the DAG is useless at best, isn’t it?</div><div class=""><br class=""></div><div class="">—escha</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 4, 2015, at 7:26 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" class="">spatel@rotateright.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Does anyone see a workaround to do this piecemeal with FMF enabled?<br class=""><br class=""></div>Otherwise, I see about 30 checks for UnsafeFPMath transforms in DAGCombiner...so I could revert r243687, start working on the combiner fixes, and then turn the flag back on when DAGCombiner is FMF-clean.<br class=""><br class="">But this wouldn't be perfect if you have more UnsafeFPMath transforms in your backend. You'd have to patch those too before we turn the flag back on.<br class=""><br class=""></div>Any other ideas about how to proceed?<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Aug 3, 2015 at 4:52 PM, escha <span dir="ltr" class=""><<a href="mailto:escha@apple.com" target="_blank" class="">escha@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">We’re getting significant CSE regressions on our backend, caused by the fact that none of the DAG folds propagate fast-math flags. This results in nodes not being CSE’d, since we only CSE nodes if they have identical flags (and thus worse codegen).<div class=""><br class=""></div><div class="">I was able to get rid of many of them by adding flag propagation to FNEG folding, but there’s way more than just that.<span class="HOEnZb"><font color="#888888" class=""><br class=""></font></span><div class=""><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">—escha</div></font></span><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On Jul 29, 2015, at 11:51 AM, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class="">For reference, fixes for PR24141 are in:<br class=""><pre class=""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243293&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=oJkUxyP-U28dL9zPjcyCjESFgqf9fEa1WxScYHC1BLE&e=" target="_blank" class="">http://reviews.llvm.org/rL243293</a>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243498&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=9UShb3DxctMQors5uP4ErkfZ2ETsaqYXEeRLX8qKYt0&e=" target="_blank" class="">http://reviews.llvm.org/rL243498</a>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243500&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=S5dEJW-NYcq9yLglX74iN2esNypm3qfP6wCNidxysx8&e=" target="_blank" class="">http://reviews.llvm.org/rL243500</a></pre>...assuming those don't cause new breakage, it's finally, really time to flip the FMF flag...and wait for more breakage.<br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jul 20, 2015 at 11:34 AM, Sanjay Patel <span dir="ltr" class=""><<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote"><span class="">On Fri, Jul 17, 2015 at 4:42 PM, Nick Lewycky <span dir="ltr" class=""><<a href="mailto:nlewycky@google.com" target="_blank" class="">nlewycky@google.com</a>></span> wrote:<br class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On 9 July 2015 at 15:27, Sanjay Patel <span dir="ltr" class=""><<a href="mailto:spatel@rotateright.com" target="_blank" class="">spatel@rotateright.com</a>></span> wrote:<br class=""><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" class=""><div class="">Hi Nick,<br class=""><br class=""></div>The reciprocal fix is in at r241826. Please let me know when you find another failure. Thanks!<br class=""></div></blockquote><div class=""><br class=""></div></span><div class="">Thank you! I tested it and found exactly nothing wrong. Hopefully I didn't goof the testing, but I think it's time to flip the flag to true, then wait a few days before removing the flag entirely.<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Wow...I'm surprised, but I'll hope for the best. Thanks for the testing!<br class=""></div><span class=""><div class=""><br class=""><br class=""></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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""></div><div class="">Note however, that we still have problems with PR24141 which is related to unsafe fp math, but doesn't change with the -enable-fmf-dag flag.</div></div></div></div></blockquote></span><div class=""><br class="">Proposed fix:<br class=""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11345&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=q0g5ELtAiUzID-3xj21ZzkiASkbrFaYCWXDy-nBF0OI&e=" rel="noreferrer" target="_blank" class="">http://reviews.llvm.org/D11345</a><br class=""> </div></div><br class=""></div></div>
</blockquote></div><br class=""></div></div></div><span class="">
_______________________________________________<br class="">llvm-commits mailing list<br class=""><a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="">llvm-commits@cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class=""></span></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>