<div dir="ltr"><div>Hi backend maintainers/hackers,<br><br></div>With r247815: <br><div><a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=247815" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=247815</a><br><br></div><div>...we're propagating fast-math-flags (FMF) from IR to DAG nodes by default. This has been reverted before...<br>But it's been one week since the commit and I haven't heard any complaints yet, so I'm hoping it sticks this time.<br><br>If you have target-specific DAG combines on FP nodes, you probably want to propagate the optimization flags from incoming nodes to nodes that you are creating. Otherwise, you may fail to get CSE optimizations that happened before this change. See the test case in the patch for an example of how that might manifest.<br><div><br>The code change when creating a node that should have FMF looks something like this: <br></div><pre>-      Tmp1 = DAG.getNode(ISD::FADD, dl, VT, Node->getOperand(0), Tmp1);
+      Tmp1 = DAG.getNode(ISD::FADD, dl, VT, Node->getOperand(0), Tmp1, Node->getFlags());
</pre><br>FMF only applies to binary FP ops at the moment, but as noted in the commit message, the plan is to extend the flags to more DAG node types.<br><br></div>Going forward, we can use the node-level flags to trigger optimizations that the global target settings (eg, DAG.getTarget().Options.UnsafeFPMath) might not allow. And some day, we may be able to remove global FP optimization flags entirely.<br><br></div>