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

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 16 11:32:52 PDT 2020


arsenm 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:
> 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.
nofpexcept is implied by the fact that this isn't STRICT_FMUL


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

https://reviews.llvm.org/D81900





More information about the llvm-commits mailing list