[PATCH] D91716: AMDGPU/GlobalISel: Calculate isKnownNeverNaN for fminnum and fmaxnum

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 18 09:31:24 PST 2020


arsenm added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-fminnum.mir:773
     %3:_(s32) = COPY $vgpr2
     %4:_(s32) = G_FMINNUM %2, %3
     $vgpr0 = COPY %4
----------------
Petar.Avramovic wrote:
> arsenm wrote:
> > Petar.Avramovic wrote:
> > > arsenm wrote:
> > > > Petar.Avramovic wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > ```
> > > > > return isKnownNeverNaN(Op.getOperand(0), SNaN, Depth + 1) ||
> > > > >        isKnownNeverNaN(Op.getOperand(1), SNaN, Depth + 1);
> > > > > }
> > > > > ```
> > > > > This is legalized first. `%2` is isKnownNeverSNaN with IEEE = true, but since inputs for `%2:_(s32) = G_FMAXNUM %0, %1` are not yet canonicalized isKnownNeverSNaN will fail and canonicalize is inserted. However since we know what will happen with `'%2:_(s32) = G_FMAXNUM %0, %1` we declare it  isKnownNeverSNaN to not depend on order of legalization.
> > > > > 
> > > > > 
> > > > The legalization order doesn't matter. These operations have their own independent semantics. isKnownNeverNaN needs to understand both pairs
> > > How can this be done?
> > > >The legalization order doesn't matter.
> > > Formula above gives different result depending if input was legalized already or not. It would work if we would legalize uses first. 
> > The same way SelectionDAG handles this:
> > 
> > ```
> >   case ISD::FMINNUM_IEEE:
> >   case ISD::FMAXNUM_IEEE: {
> >     if (SNaN)
> >       return true;
> >     // This can return a NaN if either operand is an sNaN, or if both operands
> >     // are NaN.
> >     return (isKnownNeverNaN(Op.getOperand(0), false, Depth + 1) &&
> >             isKnownNeverSNaN(Op.getOperand(1), Depth + 1)) ||
> >            (isKnownNeverNaN(Op.getOperand(1), false, Depth + 1) &&
> >             isKnownNeverSNaN(Op.getOperand(0), Depth + 1));
> >   }
> > ```
> I meant for `FMINNUM`, writing same code as in SDAG doesn't deal with unnecessary canonicalize. `FMINNUM_IEEE` is the same (there is only `if (SNaN)` part atm).
The lowering for fminnum to fminnum_ieee tries to avoid the canonicalize depending on the instruction/inputs. This is how SelectionDAG also does it. For this patch, it just needs to fully handle the correct semanics for the two pairs


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

https://reviews.llvm.org/D91716



More information about the llvm-commits mailing list