[PATCH] D25991: [PPC] Peephole to remove extra fcmp that checks for NaN

[Ehsan Amiri via llvm-commits]

amehsan added inline comments.


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.cpp:1585
+  unsigned otherReg =
+    (CROp->getOperand(1).getReg() == CopyReg ?
+                                     CROp->getOperand(2).getReg() :
----------------
nemanjai wrote:
> amehsan wrote:
> > hfinkel wrote:
> > > amehsan wrote:
> > > > hfinkel wrote:
> > > > > What is the conditional here on CopyReg actually testing. How could it be zero (i.e. an invalid register) if hasOneUse(CopyReg) was true?
> > > > The CROp has two source operands (Operands 1 and 2). If Operand(1) is the same Reg that was defined by Copy insn we just visited (CopyReg), then we look at Operand (2) and go to its definition. Otherwise, Operand(2) will be CopyReg and we should start from Operand(1) and go to its definition, etc. 
> > > I still don't understand. CopyReg is defined above as:
> > > 
> > >   unsigned CopyReg = CopyMI->getOperand(0).getReg();
> > >   if (!MRI->hasOneUse(CopyReg))
> > >     return false;
> > > 
> > > under what conditions is CopyReg zero (i.e. an invalid register)?
> > > 
> > I am probably missing something. CopyReg is the register that contains the output of COPY instruction. It should not be zero.  Maybe there are edge cases that I am not aware of ?
> But the condition is not for whether CopyReg is zero but rather whether it is the same register as the first operand of the CROR/CRNOR.
I just realized that the indentation, could cause it to be misinterpreted. I will check clang-format. 


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.cpp:1619
   // comparison with zero.
   if (OpC == PPC::FCMPUS || OpC == PPC::FCMPUD)
+    return optimizeFPCmpInstr(CmpInstr, SrcReg, SrcReg2, Mask, Value, MRI);
----------------
nemanjai wrote:
> This may be a naive question since I don't really know under which conditions we emit XSCMPUDP vs. FCMPUD, but can this not be done with XSCMPUDP as well? Or perhaps there is no need for this.
That's a good question.  The problem is PPCInstrInfo::analyzeCompare() does not return true for FCMPUD so from Peephole opt point of view XSCMPUD is not a compare opcode. Since there might be some finer points that has to be take  into account, I opened a [[ https://llvm.org/bugs/show_bug.cgi?id=30805 | PR for this ]], rather than fixing it here.


https://reviews.llvm.org/D25991