[InstCombine] treat i1 as a special type in shouldChangeType()

This patch is based on the llvm-dev discussion here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109631.html

Folding to i1 should always be desirable because that's better for value tracking 
and we have special folds for i1 types.

I checked for other users of shouldChangeType() where this might have an effect, 
but we already handle the i1 case differently than other types in all of those cases.

Side note: the default datalayout includes i1, so it seems we only find this gap in 
shouldChangeType + phi folding for the case when there is (1) an explicit datalayout 
without i1, (2) casting to i1 from a legal type, and (3) a phi with exactly 2 incoming
casted operands (as Björn mentioned).

Differential Revision: https://reviews.llvm.org/D29336

llvm-svn: 294066

1 files changed, 6 insertions, 3 deletions

diff --git a/llvm/test/Transforms/InstCombine/zext-phi.ll b/llvm/test/Transforms/InstCombine/zext-phi.ll
index 5d64b0582f0..5e352415c74 100644
--- a/llvm/test/Transforms/InstCombine/zext-phi.ll
+++ b/llvm/test/Transforms/InstCombine/zext-phi.ll
@@ -2,16 +2,19 @@
 
 target datalayout = "e-m:e-i64:64-n8:16:32:64"
 
+; Although i1 is not in the datalayout, we should treat it
+; as a legal type because it is a fundamental type in IR.
+; This means we should shrink the phi (sink the zexts).
+
 define i64 @sink_i1_casts(i1 %cond1, i1 %cond2) {
 ; CHECK-LABEL: @sink_i1_casts(
 ; CHECK-NEXT:  entry:
-; CHECK-NEXT:    [[Z1:%.*]] = zext i1 %cond1 to i64
 ; CHECK-NEXT:    br i1 %cond1, label %if, label %end
 ; CHECK:       if:
-; CHECK-NEXT:    [[Z2:%.*]] = zext i1 %cond2 to i64
 ; CHECK-NEXT:    br label %end
 ; CHECK:       end:
-; CHECK-NEXT:    [[PHI:%.*]] = phi i64 [ [[Z1]], %entry ], [ [[Z2]], %if ]
+; CHECK-NEXT:    [[PHI_IN:%.*]] = phi i1 [ %cond1, %entry ], [ %cond2, %if ]
+; CHECK-NEXT:    [[PHI:%.*]] = zext i1 [[PHI_IN]] to i64
 ; CHECK-NEXT:    ret i64 [[PHI]]
 ;
 entry: