0a3e98062f
Summary: A true or false result is expected from a comparison, but it seems the possibility of undef was overlooked, which could lead to a failed assert. This is fixed by this patch by bailing out if we encounter undef. The bug is old and the assert has been there since the end of 2014, so it seems this is unusual enough to forego optimization. Patch by JesperAntonsson. Reviewers: spatel, eeckstein, hans Reviewed By: hans Subscribers: uabelho, llvm-commits Differential Revision: https://reviews.llvm.org/D40639 llvm-svn: 319768
24 lines
738 B
LLVM
24 lines
738 B
LLVM
; RUN: opt %s -keep-loops=false -switch-to-lookup=true -simplifycfg -S | FileCheck %s
|
|
|
|
define void @f6() #0 {
|
|
; CHECK-LABEL: entry:
|
|
|
|
entry:
|
|
br label %for.cond.i
|
|
|
|
for.cond.i: ; preds = %f1.exit.i, %entry
|
|
switch i16 undef, label %f1.exit.i [
|
|
i16 -1, label %cond.false.i3.i
|
|
i16 1, label %cond.false.i3.i
|
|
i16 0, label %cond.false.i3.i
|
|
]
|
|
|
|
cond.false.i3.i: ; preds = %for.cond.i, %for.cond.i, %for.cond.i
|
|
br label %f1.exit.i
|
|
|
|
f1.exit.i: ; preds = %cond.false.i3.i, %for.cond.i
|
|
%cond.i4.i = phi i16 [ undef, %cond.false.i3.i ], [ 1, %for.cond.i ]
|
|
%tobool7.i = icmp ne i16 %cond.i4.i, 0
|
|
br label %for.cond.i
|
|
}
|