mirror of
https://github.com/RPCSX/llvm.git
synced 2024-11-24 12:19:53 +00:00
7c4d39c349
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294066 91177308-0d34-0410-b5e6-96231b3b80d8
33 lines
862 B
LLVM
33 lines
862 B
LLVM
; RUN: opt < %s -instcombine -S | FileCheck %s
|
|
|
|
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: br i1 %cond1, label %if, label %end
|
|
; CHECK: if:
|
|
; CHECK-NEXT: br label %end
|
|
; CHECK: end:
|
|
; 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:
|
|
%z1 = zext i1 %cond1 to i64
|
|
br i1 %cond1, label %if, label %end
|
|
|
|
if:
|
|
%z2 = zext i1 %cond2 to i64
|
|
br label %end
|
|
|
|
end:
|
|
%phi = phi i64 [ %z1, %entry ], [ %z2, %if ]
|
|
ret i64 %phi
|
|
}
|
|
|