fast-math-flags propagated to DAG nodes from IR instructions

Project Infrastructure LLVM Dev List Archives
1

Hi backend maintainers/hackers,

With r247815:

http://llvm.org/viewvc/llvm-project?view=revision&revision=247815

…we’re propagating fast-math-flags (FMF) from IR to DAG nodes by default. This has been reverted before…
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.

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.

The code change when creating a node that should have FMF looks something like this:

-      Tmp1 = DAG.getNode(ISD::FADD, dl, VT, Node->getOperand(0), Tmp1);
+      Tmp1 = DAG.getNode(ISD::FADD, dl, VT, Node->getOperand(0), Tmp1, Node->getFlags());

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.

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.

2

I confirmed that with a patch in our backend (an extremely FP-heavy GPU backend with tons of combines) to propagate fast-math flags on our own target DAG combines, the fast-math change Sanjay committed is NFC. Hopefully anyone else having to do the same sort of thing with their backend has the same result!

—escha