[InstSimplify] Handle trunc to i1 in Select with bit test folds.

[andjo403]

results in no changes in local run of llvm-opt-benchmark

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

[llvmbot]

@llvm/pr-subscribers-llvm-transforms

@llvm/pr-subscribers-llvm-analysis

Author: Andreas Jonson (andjo403)

Changes

Preparation to handle trunc to i1 in this fold.

results in no changes in local run of llvm-opt-benchmark

---

Full diff: https://github.com/llvm/llvm-project/pull/122944.diff

1 Files Affected:

• (modified) llvm/lib/Analysis/InstructionSimplify.cpp (+13-13)

diff --git a/llvm/lib/Analysis/InstructionSimplify.cpp b/llvm/lib/Analysis/InstructionSimplify.cpp
index d69747e30f884d..05dedd219c2667 100644
--- a/llvm/lib/Analysis/InstructionSimplify.cpp
+++ b/llvm/lib/Analysis/InstructionSimplify.cpp
@@ -4612,14 +4612,16 @@ static Value *simplifyCmpSelOfMaxMin(Value *CmpLHS, Value *CmpRHS,
   return nullptr;
 }
 
-/// An alternative way to test if a bit is set or not uses sgt/slt instead of
-/// eq/ne.
-static Value *simplifySelectWithFakeICmpEq(Value *CmpLHS, Value *CmpRHS,
-                                           CmpPredicate Pred, Value *TrueVal,
-                                           Value *FalseVal) {
-  if (auto Res = decomposeBitTestICmp(CmpLHS, CmpRHS, Pred))
-    return simplifySelectBitTest(TrueVal, FalseVal, Res->X, &Res->Mask,
-                                 Res->Pred == ICmpInst::ICMP_EQ);
+/// An alternative way to test if a bit is set or not uses e.g. sgt/slt instead
+/// of eq/ne.
+static Value *simplifySelectWithBitTest(Value *CondVal, Value *TrueVal,
+                                        Value *FalseVal) {
+
+  if (auto *ICmp = dyn_cast<ICmpInst>(CondVal))
+    if (auto Res = decomposeBitTestICmp(
+            ICmp->getOperand(0), ICmp->getOperand(1), ICmp->getPredicate()))
+      return simplifySelectBitTest(TrueVal, FalseVal, Res->X, &Res->Mask,
+                                   Res->Pred == ICmpInst::ICMP_EQ);
 
   return nullptr;
 }
@@ -4728,11 +4730,6 @@ static Value *simplifySelectWithICmpCond(Value *CondVal, Value *TrueVal,
       return FalseVal;
   }
 
-  // Check for other compares that behave like bit test.
-  if (Value *V =
-          simplifySelectWithFakeICmpEq(CmpLHS, CmpRHS, Pred, TrueVal, FalseVal))
-    return V;
-
   // If we have a scalar equality comparison, then we know the value in one of
   // the arms of the select. See if substituting this value into the arm and
   // simplifying the result yields the same value as the other arm.
@@ -4984,6 +4981,9 @@ static Value *simplifySelectInst(Value *Cond, Value *TrueVal, Value *FalseVal,
           simplifySelectWithICmpCond(Cond, TrueVal, FalseVal, Q, MaxRecurse))
     return V;
 
+  if (Value *V = simplifySelectWithBitTest(Cond, TrueVal, FalseVal))
+    return V;
+
   if (Value *V = simplifySelectWithFCmp(Cond, TrueVal, FalseVal, Q, MaxRecurse))
     return V;
 

[dtcxzyw]

LG

[nikic]

In terms of general approach, could you please land #122179, add trunc support to it, and then update folds together with added test coverage for the change?

[andjo403]

As there is a lot of regressions when adding handling for trunk in foldLogOpOfMaskedICmps I instead added the update of decomposeBitTest in this PR.

Still results in no changes in local run of llvm-opt-benchmark, this can be due to trunc to i1 is not that common yet, but also at least the test bittest_trunc_or is folded to the same with instcombine as this InstSimplify fold.

[goldsteinn]

Think the LookThruTrunc logic is untested.

[andjo403]

good catch test added.

[goldsteinn]

What is the motivation for LookThruTrunc? Doesn't (trunc (trunc X)) always get folded to (trunc X) in InstCombine?

[andjo403]

There seems to be no motivation to handle the LookThruTrunc for the trunc case as you say it is folded to one trunc, I did not think all the way and thought that an extra use of the first trunc stopped that fold but it did not.

[andjo403]

Hmm have tested this with a local run of llvm-opt-benchmark after folding fold icmp ne (and X, 1), 0 --> trunc X to N x i1 and there is still no changes with this fold so shall I abandon this commit?

[andjo403]

when I did the analysis in #119196 (comment) I only searched in the code after folds with the bit test pattern I did not test if any of the patterns happen in llvm-opt-benchmark, but maybe possible that some of the other folds will result in this pattern.

[goldsteinn]

LGTM