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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314971
91177308-0d34-0410-b5e6-
96231b3b80d8
if (!Op1CV->isNullValue() && (*Op1CV != KnownZeroMask)) {
// (X&4) == 2 --> false
// (X&4) != 2 --> true
- Constant *Res = ConstantInt::get(Type::getInt1Ty(CI.getContext()),
- isNE);
- Res = ConstantExpr::getZExt(Res, CI.getType());
+ Constant *Res = ConstantInt::get(CI.getType(), isNE);
return replaceInstUsesWith(CI, Res);
}
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
+}