[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