In r131488 I misunderstood how VREV works. It splits the vector in half and splits each half. Therefore, the real problem was that we were using a VREV64 for a 4xi16, when we should have been using a VREV32.
Updated test case and reverted change to the PerfectShuffle Table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131529 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/CodeGen/ARM/vrev.ll b/test/CodeGen/ARM/vrev.ll
index 89e2227..0f0ea2b 100644
--- a/test/CodeGen/ARM/vrev.ll
+++ b/test/CodeGen/ARM/vrev.ll
@@ -148,12 +148,11 @@
ret void
}
-; Test the shuffle of a 4xi16 which exposed a problem with the perfect shuffle table
-; entry for vrev.
+; vrev <4 x i16> should use VREV32 and not VREV64
define void @test_vrev64(<4 x i16>* nocapture %source, <2 x i16>* nocapture %dst) nounwind ssp {
; CHECK: test_vrev64:
-; CHECK: vrev64.16
; CHECK: vext.16
+; CHECK: vrev32.16
entry:
%0 = bitcast <4 x i16>* %source to <8 x i16>*
%tmp2 = load <8 x i16>* %0, align 4