[PATCH] D81900: Add coverage for inexact constant folding for multiplication in Selection DAG

[Michael Berg via Phabricator via llvm-commits]

mcberg2017 marked an inline comment as done.
mcberg2017 added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5139-5140
+          RHS.multiply(LHS, APFloat::rmNearestTiesToEven);
+      if (((status & APFloat::opInexact) == 0) ||
+          getTarget().Options.UnsafeFPMath) {
+        return getConstantFP(RHS, DL, VT);
----------------
mcberg2017 wrote:
> arsenm wrote:
> > mcberg2017 wrote:
> > > arsenm wrote:
> > > > 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
> > > 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.
> > 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
> In the way of something more refined, we could use fmf:
> 
> * Flags that would not add context: nnan, nsz, ninf, contract, arcp.  
> * However: afn and NoFPExcept could easily be used.  The flag reassoc implies relaxed precision, so possibly that too.
> 
> Some discussion?
> 
> 
> 
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.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81900/new/

https://reviews.llvm.org/D81900