[PATCH] D40554: [PowerPC] Fix bugs in sign-/zero-extension elimination

Hiroshi Inoue via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 6 07:34:20 PST 2018


inouehrs marked 8 inline comments as done.
inouehrs added inline comments.


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.cpp:3249
     // If this is a copy from another register, we recursively check source.
-    if (!TargetRegisterInfo::isVirtualRegister(SrcReg))
-      return false;
-    const MachineInstr *SrcMI = MRI->getVRegDef(SrcReg);
-    if (SrcMI != NULL)
-      return isSignOrZeroExtended(*SrcMI, SignExt, Depth);
-
-    return false;
+    return isSignOrZeroExtended(SrcReg, SignExt, Depth, MRI);
   }
----------------
nemanjai wrote:
> Seems a bit misleading to have a depth parameter that is not actually respected if we're looking through a chain of copies. Although of course, deep chains of copies shouldn't happen in practice.
I changed the names of variable and constant to indicate they shows the depth of binary operators.


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.cpp:3254
+  // So, we track the operand register as we do for register copy.
   case PPC::ANDIo:
   case PPC::ORI:
----------------
nemanjai wrote:
> Why does the register input matter for `and`-immediate?
Good catch. I fixed.


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.cpp:3317
 
-    assert(MI.getOperand(1).isReg() && MI.getOperand(2).isReg());
-
-    unsigned SrcReg1 = MI.getOperand(1).getReg();
-    unsigned SrcReg2 = MI.getOperand(2).getReg();
+    assert(MI->getOperand(1).isReg() && MI->getOperand(2).isReg());
 
----------------
nemanjai wrote:
> Comment with the assert.
I added comment, but I feel this assert is not necessary.


================
Comment at: lib/Target/PowerPC/PPCInstrInfo.h:343
 
-  bool isSignOrZeroExtended(const MachineInstr &MI, bool SignExt,
-                            const unsigned PhiDepth) const;
+  bool isSignOrZeroExtended(const unsigned Reg, bool SignExt,
+                            const unsigned PhiDepth,
----------------
nemanjai wrote:
> I still think this setup with separate queries for sign/zero/any extend seems unnecessarily complex. Seems like it would be clearer if we had an enum for the extension type (sign, zero, none) and we just have a single query that will return this. Therefore no need for Boolean parameters, no need for multiple functions, etc.
I agree that the single query approach is cleaner. But I am afraid that it will increase the cost of compilation slightly since it always checks for both sign- and zero-extensions. Do you think the potential increase in compilation cost does not matter too much here?


https://reviews.llvm.org/D40554





More information about the llvm-commits mailing list