[llvm] [RISCV][GISel] Select G_SELECT (G_ICMP, A, B) (PR #68247)

[Craig Topper via llvm-commits]

================
@@ -376,6 +391,120 @@ bool RISCVInstructionSelector::selectSExtInreg(MachineInstr &MI,
   return true;
 }
 
+/// Returns the RISCVCC::CondCode that corresponds to the CmpInst::Predicate CC.
+/// CC Must be an ICMP Predicate.
+static RISCVCC::CondCode getRISCVCCFromICMP(CmpInst::Predicate CC) {
+  switch (CC) {
+  default:
+    llvm_unreachable("Expected ICMP CmpInst::Predicate.");
+  case CmpInst::Predicate::ICMP_EQ:
+    return RISCVCC::COND_EQ;
+  case CmpInst::Predicate::ICMP_NE:
+    return RISCVCC::COND_NE;
+  case CmpInst::Predicate::ICMP_ULT:
+    return RISCVCC::COND_LTU;
+  case CmpInst::Predicate::ICMP_SLT:
+    return RISCVCC::COND_LT;
+  case CmpInst::Predicate::ICMP_UGE:
+    return RISCVCC::COND_GEU;
+  case CmpInst::Predicate::ICMP_SGE:
+    return RISCVCC::COND_GE;
+  }
+}
+
+void RISCVInstructionSelector::getICMPOperandsForBranch(
+    MachineInstr &MI, MachineIRBuilder &MIB, MachineRegisterInfo &MRI,
+    RISCVCC::CondCode &CC, Register &LHS, Register &RHS) const {
+  assert(MI.getOpcode() == TargetOpcode::G_ICMP);
+  CmpInst::Predicate ICMPCC =
+      static_cast<CmpInst::Predicate>(MI.getOperand(1).getPredicate());
+  LHS = MI.getOperand(2).getReg();
+  RHS = MI.getOperand(3).getReg();
+
+  // Adjust comparisons to use comparison with 0 if possible.
+  MachineInstr *MaybeConstant = MRI.getVRegDef(RHS);
+  if (MaybeConstant && MaybeConstant->getOpcode() == TargetOpcode::G_CONSTANT) {
----------------
topperc wrote:

> > I don't see why we should use look through here if we wouldn't have gotten look through using a tblgen pattern.
> 
> Why's that? Wouldn't we prefer an implementation that is more capable of optimizing?

We're still in the bring up phase focusing on -O0 not necessarily optimization. It feels premature to me to make a G_ICMP used by a select capable of being optimized differently than a G_ICMP by itself. Look through isn't free, it would have a compile time cost, though it is probably small it is somewhat counter to -O0. With optimizations enabled, shouldn't constant folding combines have already folded the constant chain? Are we talking about a real optimization opportunity or just something hypothetical? If there's a real missed opportunity than it feels like improving constant folding would give more improvement so that the imported tblgen patterns get the benefit since there are many more of those.

https://github.com/llvm/llvm-project/pull/68247