X86: PerformOrCombine introduced a vselect node with a wrong order of operands. This bug was introduced when a dedicated blend sdnode was replaced with the vselect node (in 139479).

llvm-svn: 145488
This commit is contained in:
Nadav Rotem 2011-11-30 10:13:37 +00:00
parent 2a0fc05456
commit f8e096f4ee
2 changed files with 23 additions and 1 deletions

View File

@ -13903,7 +13903,7 @@ static SDValue PerformOrCombine(SDNode *N, SelectionDAG &DAG,
X = DAG.getNode(ISD::BITCAST, DL, BlendVT, X);
Y = DAG.getNode(ISD::BITCAST, DL, BlendVT, Y);
Mask = DAG.getNode(ISD::BITCAST, DL, BlendVT, Mask);
Mask = DAG.getNode(ISD::VSELECT, DL, BlendVT, Mask, X, Y);
Mask = DAG.getNode(ISD::VSELECT, DL, BlendVT, Mask, Y, X);
return DAG.getNode(ISD::BITCAST, DL, VT, Mask);
}
}

View File

@ -0,0 +1,22 @@
; RUN: llc < %s -mcpu=corei7 | FileCheck %s
; Test that the order of operands is correct
; CHECK: select_func
; CHECK: pblendvb %xmm1, %xmm2
; CHECK: ret
define void @select_func() {
entry:
%c.lobit.i.i.i = ashr <8 x i16> <i16 17, i16 5, i16 1, i16 15, i16 19, i16 15, i16 4, i16 1> , <i16 15, i16 15, i16 15, i16 15, i16 15, i16 15, i16 15, i16 15>
%a35 = bitcast <8 x i16> %c.lobit.i.i.i to <2 x i64>
%and.i56.i.i.i = and <8 x i16> %c.lobit.i.i.i, <i16 25, i16 8, i16 65, i16 25, i16 8, i16 95, i16 15, i16 45>
%and.i5.i.i.i = bitcast <8 x i16> %and.i56.i.i.i to <2 x i64>
%neg.i.i.i.i = xor <2 x i64> %a35, <i64 -1, i64 -1>
%and.i.i.i.i = and <2 x i64> zeroinitializer, %neg.i.i.i.i
%or.i.i.i.i = or <2 x i64> %and.i.i.i.i, %and.i5.i.i.i
%a37 = bitcast <2 x i64> %or.i.i.i.i to <8 x i16>
store <8 x i16> %a37, <8 x i16> addrspace(1)* undef, align 4
ret void
}