[InstCombine] Fold (trunc nuw A to i1) == (trunc nuw B to i1) to A == B (#133368)

Fixes #133344

Proof: https://alive2.llvm.org/ce/z/X3Uh23 

InstCombine couldn't optimize `i1` because `canonicalizeICmpBool()` was
transforming the comparison into bitwise operations before
`foldICmpTruncWithTruncOrExt()` was called.

This PR solves the ordering issue by placing
`foldICmpTruncWithTruncOrExt()` before `canonicalizeICmpBool()`.

I believe this will not cause any regressions since all tests are
passing.

Author: veera-sivarajan

llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp

@@ -7451,6 +7451,9 @@ Instruction *InstCombinerImpl::visitICmpInst(ICmpInst &I) {
     }
   }
 
+  if (Instruction *Res = foldICmpTruncWithTruncOrExt(I, Q))
+    return Res;
+
   if (Op0->getType()->isIntOrIntVectorTy(1))
     if (Instruction *Res = canonicalizeICmpBool(I, Builder))
       return Res;
@@ -7473,9 +7476,6 @@ Instruction *InstCombinerImpl::visitICmpInst(ICmpInst &I) {
   if (Instruction *Res = foldICmpUsingKnownBits(I))
     return Res;
 
-  if (Instruction *Res = foldICmpTruncWithTruncOrExt(I, Q))
-    return Res;
-
   // Test if the ICmpInst instruction is used exclusively by a select as
   // part of a minimum or maximum operation. If so, refrain from doing
   // any other folding. This helps out other analyses which understand

llvm/test/Transforms/InstCombine/icmp-of-trunc-ext.ll

@@ -409,6 +409,17 @@ define i1 @trunc_equality_either(i16 %x, i16 %y) {
   ret i1 %c
 }
 
+define i1 @trunc_equality_bool(i8 %a, i8 %b) {
+; CHECK-LABEL: @trunc_equality_bool(
+; CHECK-NEXT:    [[EQ:%.*]] = icmp eq i8 [[A:%.*]], [[B:%.*]]
+; CHECK-NEXT:    ret i1 [[EQ]]
+;
+  %at = trunc nuw i8 %a to i1
+  %bt = trunc nuw i8 %b to i1
+  %eq = icmp eq i1 %at, %bt
+  ret i1 %eq
+}
+
 define i1 @trunc_unsigned_nuw_zext(i32 %x, i8 %y) {
 ; CHECK-LABEL: @trunc_unsigned_nuw_zext(
 ; CHECK-NEXT:    [[TMP1:%.*]] = zext i8 [[Y:%.*]] to i32