Guard constant folding using inexact testing before forwarding results, also allow Unsafe to gate the optimization. This functionality was initially added to GlobalIsel internally at Apple. We are porting it into SDAG for general use. Others may want to port it back into their GlobalIsel representation after the fact. The modified tests primarily record the difference in inexact constant folding.
Diff Detail
Event Timeline
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | I'm not sure I understand why this would depend on unsafe math. Why does it matter if it was inexact? The unconstrained operations have the defined rounding mode |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | With Unsafe any contracts concerning the ability to deliver infinite precision are broken, ergo Unsafe overrides and allows the result regardless as precision is relaxed and its behavior as well. |
I find the patch description to be unintuitive.
It doesn't say *why* this is being done, what problems that causes, etc.
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | But why would there be any expectation of infinite precision here? It's the precision of the fltSemantics. I also don't understand why this would be tied to the global UnsafeFPMath option, and not something more refined |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | In the way of something more refined, we could use fmf:
Some discussion? |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | In fact NoFPExcept may be sufficient all by itself as a guard along with the test for inexact as we are talking about fp exception states and delivering a signal for inexact. I will wait to make the change to see if there is agreement. |
llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
5139–5140 | nofpexcept is implied by the fact that this isn't STRICT_FMUL |
From discussion, it seems we are fine with fmul and constant folding the way it is versed in the code today (unrevised).
I'm not sure I understand why this would depend on unsafe math. Why does it matter if it was inexact? The unconstrained operations have the defined rounding mode