[llvm] [RISCV] Xqci with Short Forward Branches (PR #161407)

[Sam Elliott via llvm-commits]

================
@@ -88,39 +88,38 @@ define signext i32 @foo(i32 signext %a, ptr %b) nounwind {
 ; RV32IXQCI-LABEL: foo:
 ; RV32IXQCI:       # %bb.0:
 ; RV32IXQCI-NEXT:    lw a2, 0(a1)
-; RV32IXQCI-NEXT:    lw a4, 0(a1)
-; RV32IXQCI-NEXT:    lw t5, 0(a1)
-; RV32IXQCI-NEXT:    lw t4, 0(a1)
-; RV32IXQCI-NEXT:    lw t3, 0(a1)
-; RV32IXQCI-NEXT:    lw t2, 0(a1)
-; RV32IXQCI-NEXT:    lw t0, 0(a1)
-; RV32IXQCI-NEXT:    lw a7, 0(a1)
-; RV32IXQCI-NEXT:    lw a6, 0(a1)
 ; RV32IXQCI-NEXT:    lw a3, 0(a1)
-; RV32IXQCI-NEXT:    lw t1, 0(a1)
+; RV32IXQCI-NEXT:    lw a4, 0(a1)
 ; RV32IXQCI-NEXT:    lw a5, 0(a1)
-; RV32IXQCI-NEXT:    bltz t1, .LBB0_2
----------------
lenary wrote:

Broadly because `t111: i32 = RISCVISD::SELECT_CC t47, Constant:i32<0>, setge:ch, t112, t51` was getting selected into `t111: i32 = Select_GPR_Using_CC_GPR t47, Register:i32 $x0, TargetConstant:i32<3> /*==RISCVCC::COND_GE*/, t112, t51`.

This is due to the pattern here: https://github.com/llvm/llvm-project/blob/5b40491a12bad82aa5ae41ca453bab319ef800e0/llvm/lib/Target/RISCV/RISCVInstrInfo.td#L1666-L1669 which has `Complexity=8`.

There was only the generic `QC_MVGE` pattern for `SETGE`, which has complexity=3. We did have some `Complexity=8` patterns with 0 literals (for `QC_MVccI`, but only for SETEQ/SETNE: https://github.com/llvm/llvm-project/blob/5b40491a12bad82aa5ae41ca453bab319ef800e0/llvm/lib/Target/RISCV/RISCVInstrInfoXqci.td#L1544-L1547

This PR wrapped up the latter patterns into `QCIMVCCIZeroPat`, and added variants for all the condition codes supported.

These two patterns being almost identical and having the same complexity is not a problem, because the `Select_GPR_Using_CC_GPR` has a custom inserter, which adds to the cost in `getResultPatternCost` as used by the `PatternSortingPredicate`, so it will always come after a single-instruction result with no custom inserter, as is present in `QCIMVCCIZeroPat`.

I've been trying to work through internally to make sure that all our patterns are totally ordered with `PatternSortingPredicate` (when the patterns are enabled). We have one last place where there's an overlap and that sorting predicate is not able to differentiate the patterns, which we know we need to solve.

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