[InstCombine] Fix a vector splat handling bug in transformZExtICmp.

We were using an i1 type and then zero extending to a vector. Instead just create the 0/1 directly as a ConstantInt with the correct type. No need to ask ConstantExpr to zero extend for us.

This bug is a bit tricky to hit because it requires us to visit a zext of an icmp that would normally be simplified to true/false, but that icmp hasnt' been visited yet. In the test case this zext and icmp were created by visiting a udiv and due to worklist ordering we got to the zext first.

Fixes PR34841.

llvm-svn: 314971

1 files changed, 9 insertions, 0 deletions

diff --git a/llvm/test/Transforms/InstCombine/div.ll b/llvm/test/Transforms/InstCombine/div.ll
index b323e31e63e..42da1382f97 100644
--- a/llvm/test/Transforms/InstCombine/div.ll
+++ b/llvm/test/Transforms/InstCombine/div.ll
@@ -553,3 +553,12 @@ define i32 @shrink_no3(i16 %x) {
   ret i32 %div
 }
 
+; This previously crashed when trying to simplify the zext/icmp this becomes.
+define <2 x i8> @PR34841(<2 x i8> %x) {
+; CHECK-LABEL: @PR34841(
+; CHECK-NEXT:    ret <2 x i8> zeroinitializer
+;
+  %neg = and <2 x i8> %x, <i8 2, i8 2>
+  %div = udiv <2 x i8> <i8 1, i8 1>, %neg
+  ret <2 x i8> %div
+}