RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-28 14:32:51 +01:00
Code Issues Projects Releases Wiki Activity
3b17c8daa8
llvm-mirror/test/CodeGen/X86/vector-shuffle-256-v16.ll

1569 lines
86 KiB
LLVM
Raw Normal View History

[x86] Now that the new vector shuffle legality is enabled and everything is going well, remove the flag and the code for the old legality tests. This is the first step toward removing the entire old vector shuffle lowering. *Much* more code to delete coming up next. llvm-svn: 229963
2015-02-20 04:59:35 +01:00
; RUN: llc < %s -mcpu=x86-64 -mattr=+avx | FileCheck %s --check-prefix=ALL --check-prefix=AVX1
; RUN: llc < %s -mcpu=x86-64 -mattr=+avx2 | FileCheck %s --check-prefix=ALL --check-prefix=AVX2
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
target triple = "x86_64-unknown-unknown"
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %ymm0
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_01_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_01_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,1,0,3]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm0[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,5,4]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_00_01_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 1, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_02_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_02_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_00_02_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 2, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_03_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_03_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_00_03_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 3, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_04_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_04_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_00_04_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 4, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_05_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_05_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_00_05_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 5, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_00_06_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_06_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_00_06_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 6, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_08_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_08_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm1 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,0,1,0,1,0,1,0,1,0,1,2,3]
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_08_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[u,u,u,u,u,u,u,u,u,u,u,u,u,u,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Teach the new vector shuffle lowering about VBROADCAST and VPBROADCAST. This has the somewhat expected pervasive impact. I don't know why I forgot about this. Everything seems good with lots of significant improvements in the tests. llvm-svn: 218724
2014-10-01 02:41:21 +02:00
; AVX2-NEXT: vpbroadcastw %xmm0, %ymm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255]
[x86] Teach the new vector shuffle lowering a fancier way to lower 256-bit vectors with lane-crossing. Rather than immediately decomposing to 128-bit vectors, try flipping the 256-bit vector lanes, shuffling them and blending them together. This reduces our worst case shuffle by a pretty significant margin across the board. llvm-svn: 218446
2014-09-25 12:21:15 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm1, %ymm0, %ymm0
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_09_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_09_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm1 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,0,1,0,1,0,1,0,1,6,7,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_09_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = <0,0,255,255,u,u,u,u,u,u,u,u,u,u,u,u,255,255,u,u,u,u,u,u,u,u,u,u,u,u,u,u>
[x86] Teach the new vector shuffle lowering a fancier way to lower 256-bit vectors with lane-crossing. Rather than immediately decomposing to 128-bit vectors, try flipping the 256-bit vector lanes, shuffling them and blending them together. This reduces our worst case shuffle by a pretty significant margin across the board. llvm-svn: 218446
2014-09-25 12:21:15 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm1, %ymm0, %ymm0
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 9, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_10_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_10_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm1 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,0,1,0,1,0,1,10,11,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_10_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 10, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_11_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_11_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm1 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,0,1,0,1,14,15,0,1,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_11_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 11, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_12_00_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_12_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Teach the 128-bit vector shuffle lowering routines to take advantage of the existence of a reasonable blend instruction. The 256-bit vector shuffle lowering has leveraged the general technique of decomposed shuffles and blends for quite some time, but this never made it back into the 128-bit code, and there are a large number of patterns where this is substantially better. For example, this removes almost all domain crossing in vector shuffles that involve some blend and some permutation with SSE4.1 and later. See the massive reduction in 'shufps' for integer test cases in this commit. This isn't perfect yet for a few reasons: 1) The v8i16 shuffle lowering continues to plague me. We don't always form an unpack-based blend when that would be better. But the wins pretty drastically outstrip the losses here. 2) The v16i8 shuffle lowering is just a disaster here. I never went and implemented blend support here for some terrible reason. I'll do that next probably. I've not updated it for now. More variations on this technique are coming as well -- we don't shuffle-into-unpack or shuffle-into-palignr, both of which would also be profitable. Note that some test cases grow significantly in the number of instructions, but I expect to actually be faster. We use pshufd+pshufd+blendw instead of a single shufps, but the pshufd's are very likely to pipeline well (two ports on most modern intel chips) and the blend is a *very* fast instruction. The domain switch penalty will essentially always be more than a blend instruction, which is the only increase in tree height. llvm-svn: 229350
2015-02-16 02:52:02 +01:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm0[0,1,2,3],xmm1[4,5,6,7]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_12_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 12, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_13_00_00_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_13_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Teach the 128-bit vector shuffle lowering routines to take advantage of the existence of a reasonable blend instruction. The 256-bit vector shuffle lowering has leveraged the general technique of decomposed shuffles and blends for quite some time, but this never made it back into the 128-bit code, and there are a large number of patterns where this is substantially better. For example, this removes almost all domain crossing in vector shuffles that involve some blend and some permutation with SSE4.1 and later. See the massive reduction in 'shufps' for integer test cases in this commit. This isn't perfect yet for a few reasons: 1) The v8i16 shuffle lowering continues to plague me. We don't always form an unpack-based blend when that would be better. But the wins pretty drastically outstrip the losses here. 2) The v16i8 shuffle lowering is just a disaster here. I never went and implemented blend support here for some terrible reason. I'll do that next probably. I've not updated it for now. More variations on this technique are coming as well -- we don't shuffle-into-unpack or shuffle-into-palignr, both of which would also be profitable. Note that some test cases grow significantly in the number of instructions, but I expect to actually be faster. We use pshufd+pshufd+blendw instead of a single shufps, but the pshufd's are very likely to pipeline well (two ports on most modern intel chips) and the blend is a *very* fast instruction. The domain switch penalty will essentially always be more than a blend instruction, which is the only increase in tree height. llvm-svn: 229350
2015-02-16 02:52:02 +01:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm0[0,1,2,3],xmm1[4,5,6,7]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_13_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 13, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_14_00_00_00_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_14_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Teach the 128-bit vector shuffle lowering routines to take advantage of the existence of a reasonable blend instruction. The 256-bit vector shuffle lowering has leveraged the general technique of decomposed shuffles and blends for quite some time, but this never made it back into the 128-bit code, and there are a large number of patterns where this is substantially better. For example, this removes almost all domain crossing in vector shuffles that involve some blend and some permutation with SSE4.1 and later. See the massive reduction in 'shufps' for integer test cases in this commit. This isn't perfect yet for a few reasons: 1) The v8i16 shuffle lowering continues to plague me. We don't always form an unpack-based blend when that would be better. But the wins pretty drastically outstrip the losses here. 2) The v16i8 shuffle lowering is just a disaster here. I never went and implemented blend support here for some terrible reason. I'll do that next probably. I've not updated it for now. More variations on this technique are coming as well -- we don't shuffle-into-unpack or shuffle-into-palignr, both of which would also be profitable. Note that some test cases grow significantly in the number of instructions, but I expect to actually be faster. We use pshufd+pshufd+blendw instead of a single shufps, but the pshufd's are very likely to pipeline well (two ports on most modern intel chips) and the blend is a *very* fast instruction. The domain switch penalty will essentially always be more than a blend instruction, which is the only increase in tree height. llvm-svn: 229350
2015-02-16 02:52:02 +01:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm0[0,1,2,3],xmm1[4,5,6,7]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_14_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 14, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_15_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_15_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Teach the 128-bit vector shuffle lowering routines to take advantage of the existence of a reasonable blend instruction. The 256-bit vector shuffle lowering has leveraged the general technique of decomposed shuffles and blends for quite some time, but this never made it back into the 128-bit code, and there are a large number of patterns where this is substantially better. For example, this removes almost all domain crossing in vector shuffles that involve some blend and some permutation with SSE4.1 and later. See the massive reduction in 'shufps' for integer test cases in this commit. This isn't perfect yet for a few reasons: 1) The v8i16 shuffle lowering continues to plague me. We don't always form an unpack-based blend when that would be better. But the wins pretty drastically outstrip the losses here. 2) The v16i8 shuffle lowering is just a disaster here. I never went and implemented blend support here for some terrible reason. I'll do that next probably. I've not updated it for now. More variations on this technique are coming as well -- we don't shuffle-into-unpack or shuffle-into-palignr, both of which would also be profitable. Note that some test cases grow significantly in the number of instructions, but I expect to actually be faster. We use pshufd+pshufd+blendw instead of a single shufps, but the pshufd's are very likely to pipeline well (two ports on most modern intel chips) and the blend is a *very* fast instruction. The domain switch penalty will essentially always be more than a blend instruction, which is the only increase in tree height. llvm-svn: 229350
2015-02-16 02:52:02 +01:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm0[0,1,2,3],xmm1[4,5,6,7]
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm1[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_15_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm1 = ymm0[2,3,0,1]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0,1],ymm1[2,3,4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 15, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_00_00_08_08_08_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_08_08_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_00_00_08_08_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_07_07_07_07_07_07_07_15_15_15_15_15_15_15_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_07_07_07_07_07_07_07_07_15_15_15_15_15_15_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [14,15,14,15,14,15,14,15,14,15,14,15,14,15,14,15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_07_07_07_07_07_07_07_07_15_15_15_15_15_15_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[14,15,14,15,14,15,14,15,14,15,14,15,14,15,14,15,30,31,30,31,30,31,30,31,30,31,30,31,30,31,30,31]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 7, i32 7, i32 7, i32 7, i32 7, i32 7, i32 7, i32 15, i32 15, i32 15, i32 15, i32 15, i32 15, i32 15, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_04_04_04_04_08_08_08_08_12_12_12_12(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_08_08_08_08_12_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,4,4]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_08_08_08_08_12_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 4, i32 4, i32 4, i32 4, i32 8, i32 8, i32 8, i32 8, i32 12, i32 12, i32 12, i32 12>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_03_03_03_03_07_07_07_07_11_11_11_11_15_15_15_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_03_03_03_03_07_07_07_07_11_11_11_11_15_15_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[3,3,3,3,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,7,7,7,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[3,3,3,3,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,7,7,7,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_03_03_03_03_07_07_07_07_11_11_11_11_15_15_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[6,7,6,7,6,7,6,7,14,15,14,15,14,15,14,15,22,23,22,23,22,23,22,23,30,31,30,31,30,31,30,31]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 3, i32 3, i32 3, i32 3, i32 7, i32 7, i32 7, i32 7, i32 11, i32 11, i32 11, i32 11, i32 15, i32 15, i32 15, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_02_02_04_04_06_06_08_08_10_10_12_12_14_14(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_02_02_04_04_06_06_08_08_10_10_12_12_14_14:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[0,0,2,2,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,6,6]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,2,2,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,6,6]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_02_02_04_04_06_06_08_08_10_10_12_12_14_14:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,4,5,4,5,8,9,8,9,12,13,12,13,16,17,16,17,20,21,20,21,24,25,24,25,28,29,28,29]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 2, i32 2, i32 4, i32 4, i32 6, i32 6, i32 8, i32 8, i32 10, i32 10, i32 12, i32 12, i32 14, i32 14>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_01_01_03_03_05_05_07_07_09_09_11_11_13_13_15_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_01_01_03_03_05_05_07_07_09_09_11_11_13_13_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[1,1,3,3,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,5,5,7,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[1,1,3,3,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,5,5,7,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_01_01_03_03_05_05_07_07_09_09_11_11_13_13_15_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[2,3,2,3,6,7,6,7,10,11,10,11,14,15,14,15,18,19,18,19,22,23,22,23,26,27,26,27,30,31,30,31]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 1, i32 1, i32 3, i32 3, i32 5, i32 5, i32 7, i32 7, i32 9, i32 9, i32 11, i32 11, i32 13, i32 13, i32 15, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_01_00_00_00_00_00_00_00_01_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_00_00_00_00_00_00_01_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_00_00_00_00_00_00_01_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 1, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 1, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_02_00_00_00_00_00_00_00_02_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_00_00_00_00_00_02_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_00_00_00_00_00_02_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 2, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 2, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_03_00_00_00_00_00_00_00_03_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_00_00_00_00_03_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_00_00_00_00_03_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 3, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 3, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_04_00_00_00_00_00_00_00_04_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_00_00_00_04_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_00_00_00_04_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 4, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 4, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_05_00_00_00_00_00_00_00_05_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_00_00_05_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_00_00_05_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 5, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 5, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_06_00_00_00_00_00_00_00_06_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_00_06_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_00_06_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 6, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 6, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_07_00_00_00_00_00_00_00:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: vinserti128 $1, %xmm0, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
define <16 x i16> @shuffle_v16i16_00_17_02_19_04_21_06_23_08_25_10_27_12_29_14_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_17_02_19_04_21_06_23_08_25_10_27_12_29_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm2 = xmm3[0],xmm2[1],xmm3[2],xmm2[3],xmm3[4],xmm2[5],xmm3[6],xmm2[7]
; AVX1-NEXT: vpblendw {{.*#+}} xmm0 = xmm0[0],xmm1[1],xmm0[2],xmm1[3],xmm0[4],xmm1[5],xmm0[6],xmm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_17_02_19_04_21_06_23_08_25_10_27_12_29_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7],ymm0[8],ymm1[9],ymm0[10],ymm1[11],ymm0[12],ymm1[13],ymm0[14],ymm1[15]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 17, i32 2, i32 19, i32 4, i32 21, i32 6, i32 23, i32 8, i32 25, i32 10, i32 27, i32 12, i32 29, i32 14, i32 31>
ret <16 x i16> %shuffle
}
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
define <16 x i16> @shuffle_v16i16_16_01_18_03_20_05_22_07_24_09_26_11_28_13_30_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_16_01_18_03_20_05_22_07_24_09_26_11_28_13_30_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm2 = xmm3[0],xmm2[1],xmm3[2],xmm2[3],xmm3[4],xmm2[5],xmm3[6],xmm2[7]
; AVX1-NEXT: vpblendw {{.*#+}} xmm0 = xmm1[0],xmm0[1],xmm1[2],xmm0[3],xmm1[4],xmm0[5],xmm1[6],xmm0[7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_16_01_18_03_20_05_22_07_24_09_26_11_28_13_30_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm1[0],ymm0[1],ymm1[2],ymm0[3],ymm1[4],ymm0[5],ymm1[6],ymm0[7],ymm1[8],ymm0[9],ymm1[10],ymm0[11],ymm1[12],ymm0[13],ymm1[14],ymm0[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 16, i32 1, i32 18, i32 3, i32 20, i32 5, i32 22, i32 7, i32 24, i32 9, i32 26, i32 11, i32 28, i32 13, i32 30, i32 15>
ret <16 x i16> %shuffle
}
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
define <16 x i16> @shuffle_v16i16_00_01_18_19_04_05_22_23_08_09_26_27_12_13_30_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_01_18_19_04_05_22_23_08_09_26_27_12_13_30_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vblendps {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_01_18_19_04_05_22_23_08_09_26_27_12_13_30_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 1, i32 18, i32 19, i32 4, i32 5, i32 22, i32 23, i32 8, i32 9, i32 26, i32 27, i32 12, i32 13, i32 30, i32 31>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_16_17_18_19_04_05_06_07_24_25_26_27_12_13_14_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_16_17_18_19_04_05_06_07_24_25_26_27_12_13_14_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vblendpd {{.*#+}} ymm0 = ymm1[0],ymm0[1],ymm1[2],ymm0[3]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_16_17_18_19_04_05_06_07_24_25_26_27_12_13_14_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm1[0,1],ymm0[2,3],ymm1[4,5],ymm0[6,7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 16, i32 17, i32 18, i32 19, i32 4, i32 5, i32 6, i32 7, i32 24, i32 25, i32 26, i32 27, i32 12, i32 13, i32 14, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_01_02_03_04_05_06_07_08_09_10_11_12_13_14_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_01_02_03_04_05_06_07_08_09_10_11_12_13_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm2[0,1,2,3,4,5,6],xmm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_01_02_03_04_05_06_07_08_09_10_11_12_13_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = [255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,0,0]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 31>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_16_01_02_03_04_05_06_07_08_09_10_11_12_13_14_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_16_01_02_03_04_05_06_07_08_09_10_11_12_13_14_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm1[0],xmm0[1,2,3,4,5,6,7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_16_01_02_03_04_05_06_07_08_09_10_11_12_13_14_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = [0,0,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 16, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_17_02_19_04_21_06_23_24_09_26_11_28_13_30_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_17_02_19_04_21_06_23_24_09_26_11_28_13_30_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm2 = xmm3[0],xmm2[1],xmm3[2],xmm2[3],xmm3[4],xmm2[5],xmm3[6],xmm2[7]
; AVX1-NEXT: vpblendw {{.*#+}} xmm0 = xmm0[0],xmm1[1],xmm0[2],xmm1[3],xmm0[4],xmm1[5],xmm0[6],xmm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_17_02_19_04_21_06_23_24_09_26_11_28_13_30_15:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = [255,255,0,0,255,255,0,0,255,255,0,0,255,255,0,0,0,0,255,255,0,0,255,255,0,0,255,255,0,0,255,255]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 17, i32 2, i32 19, i32 4, i32 21, i32 6, i32 23, i32 24, i32 9, i32 26, i32 11, i32 28, i32 13, i32 30, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_16_01_18_03_20_05_22_07_08_25_10_27_12_29_14_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_16_01_18_03_20_05_22_07_08_25_10_27_12_29_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm2 = xmm3[0],xmm2[1],xmm3[2],xmm2[3],xmm3[4],xmm2[5],xmm3[6],xmm2[7]
; AVX1-NEXT: vpblendw {{.*#+}} xmm0 = xmm1[0],xmm0[1],xmm1[2],xmm0[3],xmm1[4],xmm0[5],xmm1[6],xmm0[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_16_01_18_03_20_05_22_07_08_25_10_27_12_29_14_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vmovdqa {{.*#+}} ymm2 = [0,0,255,255,0,0,255,255,0,0,255,255,0,0,255,255,255,255,0,0,255,255,0,0,255,255,0,0,255,255,0,0]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: vpblendvb %ymm2, %ymm0, %ymm1, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 16, i32 1, i32 18, i32 3, i32 20, i32 5, i32 22, i32 7, i32 8, i32 25, i32 10, i32 27, i32 12, i32 29, i32 14, i32 31>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_01_18_19_20_21_06_07_08_09_26_27_12_13_30_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_01_18_19_20_21_06_07_08_09_26_27_12_13_30_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vblendps {{.*#+}} ymm0 = ymm0[0],ymm1[1,2],ymm0[3,4],ymm1[5],ymm0[6],ymm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_01_18_19_20_21_06_07_08_09_26_27_12_13_30_31:
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0],ymm1[1,2],ymm0[3,4],ymm1[5],ymm0[6],ymm1[7]
[x86] Fix the v16i16 blend logic I added in the prior commit and add the missing test cases for it. Unsurprisingly, without test cases, there were bugs here. Surprisingly, this bug wasn't caught at compile time. Yep, there is an X86ISD::BLENDV. It isn't wired to anything. Oops. I'll fix than next. llvm-svn: 218434
2014-09-25 03:13:38 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 1, i32 18, i32 19, i32 20, i32 21, i32 6, i32 7, i32 8, i32 9, i32 26, i32 27, i32 12, i32 13, i32 30, i32 31>
ret <16 x i16> %shuffle
}
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
define <16 x i16> @shuffle_v16i16_00_16_00_16_00_16_00_16_00_16_00_16_00_16_00_16(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_16_00_16_00_16_00_16_00_16_00_16_00_16_00_16:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,0,0,0]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_16_00_16_00_16_00_16_00_16_00_16_00_16_00_16:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Restructure the checking patterns for v16 and v32 avx2 vector shuffle lowering to allow much better blend matching. Specifically, with the new structure the code seems clearer to me and we correctly can hit the cases where merging two 128-bit lanes is a clear win and can be shuffled cheaply afterward. llvm-svn: 222539
2014-11-21 15:53:03 +01:00
; AVX2-NEXT: vpbroadcastw %xmm1, %ymm1
; AVX2-NEXT: vpbroadcastd %xmm0, %ymm0
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7],ymm0[8],ymm1[9],ymm0[10],ymm1[11],ymm0[12],ymm1[13],ymm0[14],ymm1[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_16_00_16_00_16_00_16_08_24_08_24_08_24_08_24(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_16_00_16_00_16_00_16_08_24_08_24_08_24_08_24:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm2 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vpshufd {{.*#+}} xmm2 = xmm2[0,0,0,0]
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[0,0,0,0]
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm2, %ymm0
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_16_00_16_00_16_00_16_08_24_08_24_08_24_08_24:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[u,u,0,1,u,u,0,1,u,u,0,1,u,u,0,1,u,u,16,17,u,u,16,17,u,u,16,17,u,u,16,17]
; AVX2-NEXT: vpshufd {{.*#+}} ymm0 = ymm0[0,0,0,0,4,4,4,4]
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7],ymm0[8],ymm1[9],ymm0[10],ymm1[11],ymm0[12],ymm1[13],ymm0[14],ymm1[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 0, i32 16, i32 8, i32 24, i32 8, i32 24, i32 8, i32 24, i32 8, i32 24>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_16_16_16_16_04_05_06_07_24_24_24_24_12_13_14_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_16_16_16_16_04_05_06_07_24_24_24_24_12_13_14_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm2 = xmm2[2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm3 = xmm3[0,0,0,0,4,5,6,7]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm3[0],xmm2[0]
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_16_16_16_16_04_05_06_07_24_24_24_24_12_13_14_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[0,1,0,1,0,1,0,1,u,u,u,u,u,u,u,u,16,17,16,17,16,17,16,17,u,u,u,u,u,u,u,u]
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm1[0,1],ymm0[2,3],ymm1[4,5],ymm0[6,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 16, i32 16, i32 16, i32 16, i32 4, i32 5, i32 6, i32 7, i32 24, i32 24, i32 24, i32 24, i32 12, i32 13, i32 14, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_19_18_17_16_07_06_05_04_27_26_25_24_15_14_13_12(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_19_18_17_16_07_06_05_04_27_26_25_24_15_14_13_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm2 = xmm2[3,2,1,0,4,5,6,7]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpshufd {{.*#+}} xmm3 = xmm3[2,3,2,3]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm3 = xmm3[3,2,1,0,4,5,6,7]
; AVX1-NEXT: vpunpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[3,2,1,0,4,5,6,7]
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,2,3]
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[3,2,1,0,4,5,6,7]
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpunpcklqdq {{.*#+}} xmm0 = xmm1[0],xmm0[0]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_19_18_17_16_07_06_05_04_27_26_25_24_15_14_13_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm1[0,1],ymm0[2,3],ymm1[4,5],ymm0[6,7]
[x86] Teach the decomposed shuffle/blend lowering to use an early blend when that will allow it to lower with a single permute instead of multiple permutes. It tries to detect when it will only have to do a single permute in either case to maximize folding of loads and such. This cuts a *lot* of the avx2 shuffle permute counts in half. =] llvm-svn: 229309
2015-02-15 13:42:15 +01:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[6,7,4,5,2,3,0,1,14,15,12,13,10,11,8,9,22,23,20,21,18,19,16,17,30,31,28,29,26,27,24,25]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 19, i32 18, i32 17, i32 16, i32 7, i32 6, i32 5, i32 4, i32 27, i32 26, i32 25, i32 24, i32 15, i32 14, i32 13, i32 12>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_19_18_17_16_03_02_01_00_27_26_25_24_11_10_09_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_19_18_17_16_03_02_01_00_27_26_25_24_11_10_09_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[1],xmm2[1],xmm3[2],xmm2[2],xmm3[3],xmm2[3]
; AVX1-NEXT: vmovdqa {{.*#+}} xmm3 = [12,13,8,9,4,5,0,1,14,15,10,11,6,7,2,3]
; AVX1-NEXT: vpshufb %xmm3, %xmm2, %xmm2
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
; AVX1-NEXT: vpshufb %xmm3, %xmm0, %xmm0
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_19_18_17_16_03_02_01_00_27_26_25_24_11_10_09_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[u,u,u,u,u,u,u,u,6,7,4,5,2,3,0,1,u,u,u,u,u,u,u,u,22,23,20,21,18,19,16,17]
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[6,7,4,5,2,3,0,1,u,u,u,u,u,u,u,u,22,23,20,21,18,19,16,17,u,u,u,u,u,u,u,u]
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm1[0,1],ymm0[2,3],ymm1[4,5],ymm0[6,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 19, i32 18, i32 17, i32 16, i32 3, i32 2, i32 1, i32 0, i32 27, i32 26, i32 25, i32 24, i32 11, i32 10, i32 9, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_01_00_08_08_08_08_08_08_09_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_08_08_08_08_08_08_09_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_08_08_08_08_08_08_09_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1,16,17,16,17,16,17,16,17,16,17,16,17,18,19,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 1, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 9, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_08_08_08_10_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_08_08_08_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_08_08_08_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1,16,17,16,17,16,17,16,17,16,17,20,21,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 2, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 10, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_08_11_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_08_11_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_08_11_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1,16,17,16,17,16,17,16,17,22,23,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 3, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 11, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_12_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_12_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_12_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1,16,17,16,17,16,17,24,25,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 4, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 12, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_13_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_13_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_13_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1,16,17,16,17,26,27,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 5, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 13, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_06_00_00_00_00_00_00_08_14_08_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_08_14_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_08_14_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1,16,17,28,29,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 6, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 14, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_00_00_00_00_00_00_00_15_08_08_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_15_08_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm1
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vmovdqa {{.*#+}} xmm2 = [14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vpshufb %xmm2, %xmm1, %xmm1
; AVX1-NEXT: vpshufb %xmm2, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_15_08_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1,30,31,16,17,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 15, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_16_01_17_02_18_03_19_08_24_09_25_10_26_11_27(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_08_24_09_25_10_26_11_27:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[1],xmm2[1],xmm3[2],xmm2[2],xmm3[3],xmm2[3]
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_08_24_09_25_10_26_11_27:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpunpcklwd {{.*#+}} ymm0 = ymm0[0],ymm1[0],ymm0[1],ymm1[1],ymm0[2],ymm1[2],ymm0[3],ymm1[3],ymm0[8],ymm1[8],ymm0[9],ymm1[9],ymm0[10],ymm1[10],ymm0[11],ymm1[11]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 16, i32 1, i32 17, i32 2, i32 18, i32 3, i32 19, i32 8, i32 24, i32 9, i32 25, i32 10, i32 26, i32 11, i32 27>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_04_20_05_21_06_22_07_23_12_28_13_29_14_30_15_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_04_20_05_21_06_22_07_23_12_28_13_29_14_30_15_31:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm2 = xmm3[4],xmm2[4],xmm3[5],xmm2[5],xmm3[6],xmm2[6],xmm3[7],xmm2[7]
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm0 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_04_20_05_21_06_22_07_23_12_28_13_29_14_30_15_31:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpunpckhwd {{.*#+}} ymm0 = ymm0[4],ymm1[4],ymm0[5],ymm1[5],ymm0[6],ymm1[6],ymm0[7],ymm1[7],ymm0[12],ymm1[12],ymm0[13],ymm1[13],ymm0[14],ymm1[14],ymm0[15],ymm1[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 4, i32 20, i32 5, i32 21, i32 6, i32 22, i32 7, i32 23, i32 12, i32 28, i32 13, i32 29, i32 14, i32 30, i32 15, i32 31>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_16_01_17_02_18_03_19_12_28_13_29_14_30_15_31(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_12_28_13_29_14_30_15_31:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm2 = xmm3[4],xmm2[4],xmm3[5],xmm2[5],xmm3[6],xmm2[6],xmm3[7],xmm2[7]
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_12_28_13_29_14_30_15_31:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[u,u,0,1,u,u,2,3,u,u,4,5,u,u,6,7,u,u,24,25,u,u,26,27,u,u,28,29,u,u,30,31]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,u,u,2,3,u,u,4,5,u,u,6,7,u,u,24,25,u,u,26,27,u,u,28,29,u,u,30,31,u,u]
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7],ymm0[8],ymm1[9],ymm0[10],ymm1[11],ymm0[12],ymm1[13],ymm0[14],ymm1[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 16, i32 1, i32 17, i32 2, i32 18, i32 3, i32 19, i32 12, i32 28, i32 13, i32 29, i32 14, i32 30, i32 15, i32 31>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_04_20_05_21_06_22_07_23_08_24_09_25_10_26_11_27(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_04_20_05_21_06_22_07_23_08_24_09_25_10_26_11_27:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
[x86] Don't form overly fragmented blends when splitting and re-combining shuffles because nothing was available in the wider vector type. The key observation (which I've put in the comments for future maintainers) is that at this point, no further combining is really possible. And so even though these shuffles trivially could be combined, we need to actually do that as we produce them when producing them this late in the lowering. This fixes another (huge) part of the Halide vector shuffle regressions. As it happens, this was already well covered by the tests, but I hadn't noticed how bad some of these got. The specific patterns that turn directly into unpckl/h patterns were occurring *many* times in common vector processing code. There are still more problems here sadly, but trying to incrementally tease them apart and it looks like this is the core of the problem in the splitting logic. There is some chance of regression here, you can see it in the test changes. Specifically, where we stop forming pshufb in some cases, it is possible that pshufb was in fact faster. Intel "says" that pshufb is slower than the instruction sequences replacing it. llvm-svn: 221852
2014-11-13 03:42:08 +01:00
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm2 = xmm3[0],xmm2[0],xmm3[1],xmm2[1],xmm3[2],xmm2[2],xmm3[3],xmm2[3]
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm0 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_04_20_05_21_06_22_07_23_08_24_09_25_10_26_11_27:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm1 = ymm1[u,u,8,9,u,u,10,11,u,u,12,13,u,u,14,15,u,u,16,17,u,u,18,19,u,u,20,21,u,u,22,23]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[8,9,u,u,10,11,u,u,12,13,u,u,14,15,u,u,16,17,u,u,18,19,u,u,20,21,u,u,22,23,u,u]
; AVX2-NEXT: vpblendw {{.*#+}} ymm0 = ymm0[0],ymm1[1],ymm0[2],ymm1[3],ymm0[4],ymm1[5],ymm0[6],ymm1[7],ymm0[8],ymm1[9],ymm0[10],ymm1[11],ymm0[12],ymm1[13],ymm0[14],ymm1[15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 4, i32 20, i32 5, i32 21, i32 6, i32 22, i32 7, i32 23, i32 8, i32 24, i32 9, i32 25, i32 10, i32 26, i32 11, i32 27>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_00_01_00_08_09_08_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_08_09_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,2,3,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_00_01_00_08_09_08_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,0,1,2,3,0,1,16,17,18,19,16,17,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 1, i32 0, i32 8, i32 9, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_10_08_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_10_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,4,5,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_00_02_00_00_08_08_10_08_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,0,1,4,5,0,1,0,1,16,17,16,17,20,21,16,17,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 2, i32 0, i32 0, i32 8, i32 8, i32 10, i32 8, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_11_08_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_11_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,6,7,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_03_00_00_00_08_08_08_11_08_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,6,7,0,1,0,1,0,1,16,17,16,17,16,17,22,23,16,17,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 3, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 11, i32 8, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_08_12_08_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_08_12_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,8,9,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_00_04_00_00_00_00_08_08_08_08_12_08_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,8,9,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,24,25,16,17,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 4, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 12, i32 8, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_08_08_08_13_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_08_08_08_13_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,10,11,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_05_00_00_00_00_00_08_08_08_08_08_13_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,10,11,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,26,27,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 5, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 13, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_06_00_00_00_00_00_00_08_08_08_08_08_08_14_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_08_08_08_08_08_08_14_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,12,13,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_06_00_00_00_00_00_00_08_08_08_08_08_08_14_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,12,13,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,28,29,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 6, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 14, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_00_00_00_00_00_00_00_08_08_08_08_08_08_08_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_08_08_08_08_08_08_08_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,0,1,0,1,0,1,0,1,0,1,14,15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_07_00_00_00_00_00_00_00_08_08_08_08_08_08_08_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[14,15,0,1,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,16,17,16,17,16,17,30,31]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 8, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_02_02_04_04_06_06_14_14_12_12_10_10_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_00_02_02_04_04_06_06_14_14_12_12_10_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[0,0,2,2,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,6,6]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[12,13,12,13,8,9,8,9,4,5,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_00_02_02_04_04_06_06_14_14_12_12_10_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,4,5,4,5,8,9,8,9,12,13,12,13,28,29,28,29,24,25,24,25,20,21,20,21,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 2, i32 2, i32 4, i32 4, i32 6, i32 6, i32 14, i32 14, i32 12, i32 12, i32 10, i32 10, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_04_04_04_04_00_00_00_00_08_08_08_08_12_12_12_12(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_04_04_04_04_00_00_00_00_08_08_08_08_12_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[8,9,8,9,8,9,8,9,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_04_04_04_04_00_00_00_00_08_08_08_08_12_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[8,9,8,9,8,9,8,9,0,1,0,1,0,1,0,1,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 4, i32 4, i32 4, i32 4, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 8, i32 8, i32 12, i32 12, i32 12, i32 12>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_uu_uu_00_00_00_00_00_08_08_uu_uu_08_08_14_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_uu_uu_00_00_00_00_00_08_08_uu_uu_08_08_14_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[0,1,2,3,4,5,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,4,5,6,7,0,1,0,1,12,13,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_uu_uu_00_00_00_00_00_08_08_uu_uu_08_08_14_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,u,u,u,u,0,1,0,1,0,1,0,1,0,1,16,17,16,17,u,u,u,u,16,17,16,17,28,29,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 undef, i32 undef, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 undef, i32 undef, i32 8, i32 8, i32 14, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_uu_00_00_00_00_00_00_08_08_uu_uu_08_08_08_15(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_07_uu_00_00_00_00_00_00_08_08_uu_uu_08_08_08_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[14,15,2,3,0,1,0,1,0,1,0,1,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[0,1,0,1,4,5,6,7,0,1,0,1,0,1,14,15]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_07_uu_00_00_00_00_00_00_08_08_uu_uu_08_08_08_15:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[14,15,u,u,0,1,0,1,0,1,0,1,0,1,0,1,16,17,16,17,u,u,u,u,16,17,16,17,16,17,30,31]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 undef, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 8, i32 8, i32 undef, i32 undef, i32 8, i32 8, i32 8, i32 15>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_uu_uu_02_04_04_uu_06_14_14_uu_12_10_10_08_08(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_00_uu_uu_02_04_04_uu_06_14_14_uu_12_10_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm0[0,1,2,2,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,6,6]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm0 = xmm0[12,13,12,13,12,13,8,9,4,5,4,5,0,1,0,1]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_00_uu_uu_02_04_04_uu_06_14_14_uu_12_10_10_08_08:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,u,u,u,u,4,5,8,9,8,9,u,u,12,13,28,29,28,29,u,u,24,25,20,21,20,21,16,17,16,17]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 undef, i32 undef, i32 2, i32 4, i32 4, i32 undef, i32 6, i32 14, i32 14, i32 undef, i32 12, i32 10, i32 10, i32 8, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_04_04_04_04_uu_uu_uu_uu_08_08_08_uu_uu_12_12_12(<16 x i16> %a, <16 x i16> %b) {
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-LABEL: shuffle_v16i16_04_04_04_04_uu_uu_uu_uu_08_08_08_uu_uu_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm1 = xmm0[2,1,2,3]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,3,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-LABEL: shuffle_v16i16_04_04_04_04_uu_uu_uu_uu_08_08_08_uu_uu_12_12_12:
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2: # BB#0:
[x86] Update the exact FileCheck syntax of the 256-bit and 512-bit shuffle tests to match that used in the script I posted and now used consistently in 128-bit tests. Nothing interesting changing here, just using the label name as the FileCheck label and a slightly more general comment marker consumption strategy. llvm-svn: 218709
2014-10-01 00:04:45 +02:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[8,9,8,9,8,9,8,9,u,u,u,u,u,u,u,u,16,17,16,17,16,17,u,u,u,u,24,25,24,25,24,25]
[x86] Introduce tests covering the gamut of 256-bit vector shuffling. These are just test cases, no actual code yet. This establishes the baseline fallback strategy we're starting from on AVX2 and the expected lowering we use on AVX1. Also, these test cases are very much generated. I've manually crafted the specific pattern set that I'm hoping will be useful at exercising the lowering code, but I've not (and could not) manually verify *all* of these. I've spot checked and they seem legit to me. As with the rest of vector shuffling, at a certain point the only really useful way to check the correctness of this stuff is through fuzz testing. llvm-svn: 218267
2014-09-22 22:25:08 +02:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 4, i32 4, i32 4, i32 4, i32 undef, i32 undef, i32 undef, i32 undef, i32 8, i32 8, i32 8, i32 undef, i32 undef, i32 12, i32 12, i32 12>
ret <16 x i16> %shuffle
}
[x86] Add a bunch of test cases to 256-bit shuffles that exercise merging 128-bit subvectors and also shuffling all the elements of those subvectors. Currently we generate pretty bad code for many of these, but I'm testing a patch that should dramatically improve this in addition to making the shuffle lowering robust to other changes. llvm-svn: 222525
2014-11-21 13:17:50 +01:00
define <16 x i16> @shuffle_v16i16_00_00_00_00_04_04_04_04_16_16_16_16_20_20_20_20(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_16_16_16_16_20_20_20_20:
; AVX1: # BB#0:
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_16_16_16_16_20_20_20_20:
; AVX2: # BB#0:
; AVX2-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
[x86] Teach the x86 vector shuffle lowering to detect mergable 128-bit lanes. By special casing these we can often either reduce the total number of shuffles significantly or reduce the number of (high latency on Haswell) AVX2 shuffles that potentially cross 128-bit lanes. Even when these don't actually cross lanes, they have much higher latency to support that. Doing two of them and a blend is worse than doing a single insert across the 128-bit lanes to blend and then doing a single interleaved shuffle. While this seems like a narrow case, it kept cropping up on me and the difference is *huge* as you can see in many of the test cases. I first hit this trying to perfectly fix the interleaving shuffle patterns used by Halide for AVX2. llvm-svn: 222533
2014-11-21 14:56:05 +01:00
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Add a bunch of test cases to 256-bit shuffles that exercise merging 128-bit subvectors and also shuffling all the elements of those subvectors. Currently we generate pretty bad code for many of these, but I'm testing a patch that should dramatically improve this in addition to making the shuffle lowering robust to other changes. llvm-svn: 222525
2014-11-21 13:17:50 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 4, i32 4, i32 4, i32 4, i32 16, i32 16, i32 16, i32 16, i32 20, i32 20, i32 20, i32 20>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_08_08_08_08_12_12_12_12_16_16_16_16_20_20_20_20(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_08_08_08_08_12_12_12_12_16_16_16_16_20_20_20_20:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_08_08_08_08_12_12_12_12_16_16_16_16_20_20_20_20:
; AVX2: # BB#0:
[x86] Teach the x86 vector shuffle lowering to detect mergable 128-bit lanes. By special casing these we can often either reduce the total number of shuffles significantly or reduce the number of (high latency on Haswell) AVX2 shuffles that potentially cross 128-bit lanes. Even when these don't actually cross lanes, they have much higher latency to support that. Doing two of them and a blend is worse than doing a single insert across the 128-bit lanes to blend and then doing a single interleaved shuffle. While this seems like a narrow case, it kept cropping up on me and the difference is *huge* as you can see in many of the test cases. I first hit this trying to perfectly fix the interleaving shuffle patterns used by Halide for AVX2. llvm-svn: 222533
2014-11-21 14:56:05 +01:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm0 = ymm0[2,3],ymm1[0,1]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Add a bunch of test cases to 256-bit shuffles that exercise merging 128-bit subvectors and also shuffling all the elements of those subvectors. Currently we generate pretty bad code for many of these, but I'm testing a patch that should dramatically improve this in addition to making the shuffle lowering robust to other changes. llvm-svn: 222525
2014-11-21 13:17:50 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 8, i32 8, i32 8, i32 8, i32 12, i32 12, i32 12, i32 12, i32 16, i32 16, i32 16, i32 16, i32 20, i32 20, i32 20, i32 20>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_08_08_08_08_12_12_12_12_24_24_24_24_28_28_28_28(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_08_08_08_08_12_12_12_12_24_24_24_24_28_28_28_28:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_08_08_08_08_12_12_12_12_24_24_24_24_28_28_28_28:
; AVX2: # BB#0:
[x86] Teach the x86 vector shuffle lowering to detect mergable 128-bit lanes. By special casing these we can often either reduce the total number of shuffles significantly or reduce the number of (high latency on Haswell) AVX2 shuffles that potentially cross 128-bit lanes. Even when these don't actually cross lanes, they have much higher latency to support that. Doing two of them and a blend is worse than doing a single insert across the 128-bit lanes to blend and then doing a single interleaved shuffle. While this seems like a narrow case, it kept cropping up on me and the difference is *huge* as you can see in many of the test cases. I first hit this trying to perfectly fix the interleaving shuffle patterns used by Halide for AVX2. llvm-svn: 222533
2014-11-21 14:56:05 +01:00
; AVX2-NEXT: vperm2i128 {{.*#+}} ymm0 = ymm0[2,3],ymm1[2,3]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Add a bunch of test cases to 256-bit shuffles that exercise merging 128-bit subvectors and also shuffling all the elements of those subvectors. Currently we generate pretty bad code for many of these, but I'm testing a patch that should dramatically improve this in addition to making the shuffle lowering robust to other changes. llvm-svn: 222525
2014-11-21 13:17:50 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 8, i32 8, i32 8, i32 8, i32 12, i32 12, i32 12, i32 12, i32 24, i32 24, i32 24, i32 24, i32 28, i32 28, i32 28, i32 28>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_00_00_00_00_04_04_04_04_24_24_24_24_28_28_28_28(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_24_24_24_24_28_28_28_28:
; AVX1: # BB#0:
; AVX1-NEXT: vpshuflw {{.*#+}} xmm0 = xmm0[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm0 = xmm0[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm1
; AVX1-NEXT: vpshuflw {{.*#+}} xmm1 = xmm1[0,0,0,0,4,5,6,7]
; AVX1-NEXT: vpshufhw {{.*#+}} xmm1 = xmm1[0,1,2,3,4,4,4,4]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_00_00_00_00_04_04_04_04_24_24_24_24_28_28_28_28:
; AVX2: # BB#0:
[x86] Restructure the checking patterns for v16 and v32 avx2 vector shuffle lowering to allow much better blend matching. Specifically, with the new structure the code seems clearer to me and we correctly can hit the cases where merging two 128-bit lanes is a clear win and can be shuffled cheaply afterward. llvm-svn: 222539
2014-11-21 15:53:03 +01:00
; AVX2-NEXT: vpblendd {{.*#+}} ymm0 = ymm0[0,1,2,3],ymm1[4,5,6,7]
; AVX2-NEXT: vpshufb {{.*#+}} ymm0 = ymm0[0,1,0,1,0,1,0,1,8,9,8,9,8,9,8,9,16,17,16,17,16,17,16,17,24,25,24,25,24,25,24,25]
[x86] Add a bunch of test cases to 256-bit shuffles that exercise merging 128-bit subvectors and also shuffling all the elements of those subvectors. Currently we generate pretty bad code for many of these, but I'm testing a patch that should dramatically improve this in addition to making the shuffle lowering robust to other changes. llvm-svn: 222525
2014-11-21 13:17:50 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 4, i32 4, i32 4, i32 4, i32 24, i32 24, i32 24, i32 24, i32 28, i32 28, i32 28, i32 28>
ret <16 x i16> %shuffle
}
[x86] Add some tests for a common unpack pattern of vector shuffle that has a remarkably unique and efficient lowering. While we get this some of the time already, we miss a few cases and there wasn't a principled reason we got it. We should at least test this. v8 already has tests for this pattern. llvm-svn: 222607
2014-11-22 06:44:43 +01:00
define <16 x i16> @shuffle_v16i16_00_16_01_17_02_18_03_19_04_20_05_21_06_22_07_23(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_04_20_05_21_06_22_07_23:
; AVX1: # BB#0:
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm2 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
; AVX1-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_00_16_01_17_02_18_03_19_04_20_05_21_06_22_07_23:
; AVX2: # BB#0:
; AVX2-NEXT: vpunpckhwd {{.*#+}} xmm2 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
; AVX2-NEXT: vpunpcklwd {{.*#+}} xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1],xmm0[2],xmm1[2],xmm0[3],xmm1[3]
; AVX2-NEXT: vinserti128 $1, %xmm2, %ymm0, %ymm0
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 0, i32 16, i32 1, i32 17, i32 2, i32 18, i32 3, i32 19, i32 4, i32 20, i32 5, i32 21, i32 6, i32 22, i32 7, i32 23>
ret <16 x i16> %shuffle
}
[X86][AVX2] Enabled shuffle matching for the AVX2 zero extension (128bit -> 256bit) vpmovzx* instructions. Differential Revision: http://reviews.llvm.org/D7251 llvm-svn: 228014
2015-02-03 20:34:09 +01:00
[X86][AVX2] vpslldq/vpsrldq byte shifts for AVX2 This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets. It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions. Differential Revision: http://reviews.llvm.org/D7596 llvm-svn: 229311
2015-02-15 14:19:52 +01:00
define <16 x i16> @shuffle_v16i16_zz_zz_zz_zz_zz_zz_zz_16_zz_zz_zz_zz_zz_zz_zz_24(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_zz_zz_zz_zz_zz_zz_zz_16_zz_zz_zz_zz_zz_zz_zz_24:
; AVX1: # BB#0:
[x86] Clean up a few test cases with the update script. NFC llvm-svn: 229349
2015-02-16 02:39:50 +01:00
; AVX1-NEXT: vpslldq {{.*#+}} xmm1 = zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,xmm0[0,1]
[X86][AVX2] vpslldq/vpsrldq byte shifts for AVX2 This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets. It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions. Differential Revision: http://reviews.llvm.org/D7596 llvm-svn: 229311
2015-02-15 14:19:52 +01:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Clean up a few test cases with the update script. NFC llvm-svn: 229349
2015-02-16 02:39:50 +01:00
; AVX1-NEXT: vpslldq {{.*#+}} xmm0 = zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,xmm0[0,1]
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
[X86][AVX2] vpslldq/vpsrldq byte shifts for AVX2 This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets. It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions. Differential Revision: http://reviews.llvm.org/D7596 llvm-svn: 229311
2015-02-15 14:19:52 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_zz_zz_zz_zz_zz_zz_zz_16_zz_zz_zz_zz_zz_zz_zz_24:
; AVX2: # BB#0:
; AVX2-NEXT: vpslldq {{.*#+}} ymm0 = zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,ymm0[0,1],zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,zero,ymm0[16,17]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> zeroinitializer, <16 x i16> %a, <16 x i32> <i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 16, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 24>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_17_18_19_20_21_22_23_zz_25_26_27_28_29_30_31_zz(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_17_18_19_20_21_22_23_zz_25_26_27_28_29_30_31_zz:
; AVX1: # BB#0:
[x86] Clean up a few test cases with the update script. NFC llvm-svn: 229349
2015-02-16 02:39:50 +01:00
; AVX1-NEXT: vpsrldq {{.*#+}} xmm1 = xmm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15],zero,zero
[X86][AVX2] vpslldq/vpsrldq byte shifts for AVX2 This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets. It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions. Differential Revision: http://reviews.llvm.org/D7596 llvm-svn: 229311
2015-02-15 14:19:52 +01:00
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
[x86] Clean up a few test cases with the update script. NFC llvm-svn: 229349
2015-02-16 02:39:50 +01:00
; AVX1-NEXT: vpsrldq {{.*#+}} xmm0 = xmm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15],zero,zero
[X86][AVX2] vpslldq/vpsrldq byte shifts for AVX2 This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets. It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions. Differential Revision: http://reviews.llvm.org/D7596 llvm-svn: 229311
2015-02-15 14:19:52 +01:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_17_18_19_20_21_22_23_zz_25_26_27_28_29_30_31_zz:
; AVX2: # BB#0:
; AVX2-NEXT: vpsrldq {{.*#+}} ymm0 = ymm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15],zero,zero,ymm0[18,19,20,21,22,23,24,25,26,27,28,29,30,31],zero,zero
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> zeroinitializer, <16 x i16> %a, <16 x i32> <i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 0, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 0>
ret <16 x i16> %shuffle
}
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
;
; Shuffle to logical bit shifts
;
define <16 x i16> @shuffle_v16i16_zz_00_zz_02_zz_04_zz_06_zz_08_zz_10_zz_12_zz_14(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_zz_00_zz_02_zz_04_zz_06_zz_08_zz_10_zz_12_zz_14:
; AVX1: # BB#0:
[x86] When splitting 256-bit vectors into 128-bit vectors, don't extract subvectors from buildvectors. That doesn't really make any sense and it breaks all of the down-stream matching of buildvectors to cleverly lower shuffles. With this, we now get the shift-based lowering of 256-bit vector shuffles with AVX1 when we split them into 128-bit vectors. We also do much better on the zero-extension patterns, although there remains quite a bit of room for improvement here. llvm-svn: 229299
2015-02-15 11:12:02 +01:00
; AVX1-NEXT: vpslld $16, %xmm0, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpslld $16, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_zz_00_zz_02_zz_04_zz_06_zz_08_zz_10_zz_12_zz_14:
; AVX2: # BB#0:
[x86] Mechanically update a bunch of tests' check lines using the latest version of the script. Changes include: - Using the VEX prefix - Skipping more detail when we have useful shuffle comments to match - Matching more shuffle comments that have been added to the printer (yay!) - Matching the destination registers of some AVX instructions - Stripping trailing whitespace that crept in - Fixing indentation issues Nothing interesting going on here. I'm just trying really hard to ensure these changes don't show up in the diffs with actual changes to the backend. llvm-svn: 228132
2015-02-04 11:46:53 +01:00
; AVX2-NEXT: vpslld $16, %ymm0, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> zeroinitializer, <16 x i32> <i32 16, i32 0, i32 16, i32 2, i32 16, i32 4, i32 16, i32 6, i32 16, i32 8, i32 16, i32 10, i32 16, i32 12, i32 16, i32 14>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_zz_zz_zz_00_zz_zz_zz_04_zz_zz_zz_08_zz_zz_zz_12(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_zz_zz_zz_00_zz_zz_zz_04_zz_zz_zz_08_zz_zz_zz_12:
; AVX1: # BB#0:
[x86] When splitting 256-bit vectors into 128-bit vectors, don't extract subvectors from buildvectors. That doesn't really make any sense and it breaks all of the down-stream matching of buildvectors to cleverly lower shuffles. With this, we now get the shift-based lowering of 256-bit vector shuffles with AVX1 when we split them into 128-bit vectors. We also do much better on the zero-extension patterns, although there remains quite a bit of room for improvement here. llvm-svn: 229299
2015-02-15 11:12:02 +01:00
; AVX1-NEXT: vpsllq $48, %xmm0, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpsllq $48, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_zz_zz_zz_00_zz_zz_zz_04_zz_zz_zz_08_zz_zz_zz_12:
; AVX2: # BB#0:
[x86] Mechanically update a bunch of tests' check lines using the latest version of the script. Changes include: - Using the VEX prefix - Skipping more detail when we have useful shuffle comments to match - Matching more shuffle comments that have been added to the printer (yay!) - Matching the destination registers of some AVX instructions - Stripping trailing whitespace that crept in - Fixing indentation issues Nothing interesting going on here. I'm just trying really hard to ensure these changes don't show up in the diffs with actual changes to the backend. llvm-svn: 228132
2015-02-04 11:46:53 +01:00
; AVX2-NEXT: vpsllq $48, %ymm0, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> zeroinitializer, <16 x i32> <i32 16, i32 16, i32 16, i32 0, i32 16, i32 16, i32 16, i32 4, i32 16, i32 16, i32 16, i32 8, i32 16, i32 16, i32 16, i32 12>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_01_zz_03_zz_05_zz_07_zz_09_zz_11_zz_13_zz_15_zz(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_01_zz_03_zz_05_zz_07_zz_09_zz_11_zz_13_zz_15_zz:
; AVX1: # BB#0:
[x86] When splitting 256-bit vectors into 128-bit vectors, don't extract subvectors from buildvectors. That doesn't really make any sense and it breaks all of the down-stream matching of buildvectors to cleverly lower shuffles. With this, we now get the shift-based lowering of 256-bit vector shuffles with AVX1 when we split them into 128-bit vectors. We also do much better on the zero-extension patterns, although there remains quite a bit of room for improvement here. llvm-svn: 229299
2015-02-15 11:12:02 +01:00
; AVX1-NEXT: vpsrld $16, %xmm0, %xmm1
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm0
; AVX1-NEXT: vpsrld $16, %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_01_zz_03_zz_05_zz_07_zz_09_zz_11_zz_13_zz_15_zz:
; AVX2: # BB#0:
[x86] Mechanically update a bunch of tests' check lines using the latest version of the script. Changes include: - Using the VEX prefix - Skipping more detail when we have useful shuffle comments to match - Matching more shuffle comments that have been added to the printer (yay!) - Matching the destination registers of some AVX instructions - Stripping trailing whitespace that crept in - Fixing indentation issues Nothing interesting going on here. I'm just trying really hard to ensure these changes don't show up in the diffs with actual changes to the backend. llvm-svn: 228132
2015-02-04 11:46:53 +01:00
; AVX2-NEXT: vpsrld $16, %ymm0, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> zeroinitializer, <16 x i32> <i32 1, i32 16, i32 3, i32 16, i32 5, i32 16, i32 7, i32 16, i32 9, i32 16, i32 11, i32 16, i32 13, i32 16, i32 15, i32 16>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_02_03_zz_zz_06_07_zz_zz_10_11_zz_zz_14_15_zz_zz(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_02_03_zz_zz_06_07_zz_zz_10_11_zz_zz_14_15_zz_zz:
; AVX1: # BB#0:
[SDAG] Teach the SelectionDAG to canonicalize vector shuffles of splats directly into blends of the splats. These patterns show up even very late in the vector shuffle lowering where we don't have any chance for DAG combining to kick in, and blending is a tremendously simpler operation to model. By coercing the shuffle into a blend we can much more easily match and lower shuffles of splats. Immediately with this change there are significantly more blends being matched in the x86 vector shuffle lowering. llvm-svn: 229308
2015-02-15 13:18:12 +01:00
; AVX1-NEXT: vxorps %ymm1, %ymm1, %ymm1
; AVX1-NEXT: vshufps {{.*#+}} ymm0 = ymm0[1,3],ymm1[1,3],ymm0[5,7],ymm1[5,7]
; AVX1-NEXT: vshufps {{.*#+}} ymm0 = ymm0[0,2,1,3,4,6,5,7]
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_02_03_zz_zz_06_07_zz_zz_10_11_zz_zz_14_15_zz_zz:
; AVX2: # BB#0:
[x86] Mechanically update a bunch of tests' check lines using the latest version of the script. Changes include: - Using the VEX prefix - Skipping more detail when we have useful shuffle comments to match - Matching more shuffle comments that have been added to the printer (yay!) - Matching the destination registers of some AVX instructions - Stripping trailing whitespace that crept in - Fixing indentation issues Nothing interesting going on here. I'm just trying really hard to ensure these changes don't show up in the diffs with actual changes to the backend. llvm-svn: 228132
2015-02-04 11:46:53 +01:00
; AVX2-NEXT: vpsrlq $32, %ymm0, %ymm0
[X86][SSE] psrl(w/d/q) and psll(w/d/q) bit shifts for SSE2 Patch to match cases where shuffle masks can be reduced to bit shifts. Similar to byte shift shuffle matching from D5699. Differential Revision: http://reviews.llvm.org/D6649 llvm-svn: 228047
2015-02-03 22:58:29 +01:00
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> zeroinitializer, <16 x i32> <i32 2, i32 3, i32 16, i32 16, i32 6, i32 7, i32 16, i32 16, i32 10, i32 11, i32 16, i32 16, i32 14, i32 15, i32 16, i32 16>
ret <16 x i16> %shuffle
}
[X86][AVX2] Enabled shuffle matching for the AVX2 zero extension (128bit -> 256bit) vpmovzx* instructions. Differential Revision: http://reviews.llvm.org/D7251 llvm-svn: 228014
2015-02-03 20:34:09 +01:00
define <16 x i16> @shuffle_v16i16_16_zz_zz_zz_17_zz_zz_zz_18_zz_zz_zz_19_zz_zz_zz(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_16_zz_zz_zz_17_zz_zz_zz_18_zz_zz_zz_19_zz_zz_zz:
; AVX1: # BB#0:
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpshufb {{.*#+}} xmm1 = xmm0[4,5,2,3,4,5,6,7,6,7,10,11,4,5,6,7]
[x86] When splitting 256-bit vectors into 128-bit vectors, don't extract subvectors from buildvectors. That doesn't really make any sense and it breaks all of the down-stream matching of buildvectors to cleverly lower shuffles. With this, we now get the shift-based lowering of 256-bit vector shuffles with AVX1 when we split them into 128-bit vectors. We also do much better on the zero-extension patterns, although there remains quite a bit of room for improvement here. llvm-svn: 229299
2015-02-15 11:12:02 +01:00
; AVX1-NEXT: vpxor %xmm2, %xmm2, %xmm2
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpblendw {{.*#+}} xmm1 = xmm1[0],xmm2[1,2,3],xmm1[4],xmm2[5,6,7]
; AVX1-NEXT: vpmovzxwq {{.*#+}} xmm0 = xmm0[0],zero,zero,zero,xmm0[1],zero,zero,zero
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
[X86][AVX2] Enabled shuffle matching for the AVX2 zero extension (128bit -> 256bit) vpmovzx* instructions. Differential Revision: http://reviews.llvm.org/D7251 llvm-svn: 228014
2015-02-03 20:34:09 +01:00
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_16_zz_zz_zz_17_zz_zz_zz_18_zz_zz_zz_19_zz_zz_zz:
; AVX2: # BB#0:
; AVX2-NEXT: vpmovzxwq {{.*#+}} ymm0 = xmm0[0],zero,zero,zero,xmm0[1],zero,zero,zero,xmm0[2],zero,zero,zero,xmm0[3],zero,zero,zero
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> zeroinitializer, <16 x i16> %a, <16 x i32> <i32 16, i32 0, i32 0, i32 0, i32 17, i32 0, i32 0, i32 0, i32 18, i32 0, i32 0, i32 0, i32 19, i32 0, i32 0, i32 0>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_16_zz_17_zz_18_zz_19_zz_20_zz_21_zz_22_zz_22_zz(<16 x i16> %a) {
; AVX1-LABEL: shuffle_v16i16_16_zz_17_zz_18_zz_19_zz_20_zz_21_zz_22_zz_22_zz:
; AVX1: # BB#0:
[x86] Delete still more piles of complex code now that we have a good systematic lowering of v8i16. This required a slight strategy shift to prefer unpack lowerings in more places. While this isn't a cut-and-dry win in every case, it is in the overwhelming majority. There are only a few places where the old lowering would probably be a touch faster, and then only by a small margin. In some cases, this is yet another significant improvement. llvm-svn: 229859
2015-02-19 16:21:57 +01:00
; AVX1-NEXT: vpxor %xmm1, %xmm1, %xmm1
; AVX1-NEXT: vpunpckhwd {{.*#+}} xmm1 = xmm0[4],xmm1[4],xmm0[5],xmm1[5],xmm0[6],xmm1[6],xmm0[7],xmm1[7]
[x86] When splitting 256-bit vectors into 128-bit vectors, don't extract subvectors from buildvectors. That doesn't really make any sense and it breaks all of the down-stream matching of buildvectors to cleverly lower shuffles. With this, we now get the shift-based lowering of 256-bit vector shuffles with AVX1 when we split them into 128-bit vectors. We also do much better on the zero-extension patterns, although there remains quite a bit of room for improvement here. llvm-svn: 229299
2015-02-15 11:12:02 +01:00
; AVX1-NEXT: vpmovzxwd {{.*#+}} xmm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero
[X86][AVX2] Enabled shuffle matching for the AVX2 zero extension (128bit -> 256bit) vpmovzx* instructions. Differential Revision: http://reviews.llvm.org/D7251 llvm-svn: 228014
2015-02-03 20:34:09 +01:00
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_16_zz_17_zz_18_zz_19_zz_20_zz_21_zz_22_zz_22_zz:
; AVX2: # BB#0:
; AVX2-NEXT: vpmovzxwd {{.*#+}} ymm0 = xmm0[0],zero,xmm0[1],zero,xmm0[2],zero,xmm0[3],zero,xmm0[4],zero,xmm0[5],zero,xmm0[6],zero,xmm0[7],zero
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> zeroinitializer, <16 x i16> %a, <16 x i32> <i32 16, i32 0, i32 17, i32 0, i32 18, i32 0, i32 19, i32 0, i32 20, i32 0, i32 21, i32 0, i32 22, i32 0, i32 23, i32 0>
ret <16 x i16> %shuffle
}
[X86] Add support for lowering shuffles to 256-bit PALIGNR instruction. llvm-svn: 229359
2015-02-16 07:29:06 +01:00
define <16 x i16> @shuffle_v16i16_23_00_01_02_03_04_05_06_31_08_09_10_11_12_13_14(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_23_00_01_02_03_04_05_06_31_08_09_10_11_12_13_14:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpalignr {{.*#+}} xmm2 = xmm2[14,15],xmm3[0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm1[14,15],xmm0[0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_23_00_01_02_03_04_05_06_31_08_09_10_11_12_13_14:
; AVX2: # BB#0:
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm1[14,15],ymm0[0,1,2,3,4,5,6,7,8,9,10,11,12,13],ymm1[30,31],ymm0[16,17,18,19,20,21,22,23,24,25,26,27,28,29]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 23, i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 31, i32 8, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_01_02_03_04_05_06_07_16_09_10_11_12_13_14_15_24(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_01_02_03_04_05_06_07_16_09_10_11_12_13_14_15_24:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpalignr {{.*#+}} xmm2 = xmm2[2,3,4,5,6,7,8,9,10,11,12,13,14,15],xmm3[0,1]
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15],xmm1[0,1]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_01_02_03_04_05_06_07_16_09_10_11_12_13_14_15_24:
; AVX2: # BB#0:
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15],ymm1[0,1],ymm0[18,19,20,21,22,23,24,25,26,27,28,29,30,31],ymm1[16,17]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 16, i32 9, i32 10, i32 11, i32 12, i32 13, i32 14, i32 15, i32 24>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_17_18_19_20_21_22_23_00_25_26_27_28_29_30_31_8(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_17_18_19_20_21_22_23_00_25_26_27_28_29_30_31_8:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm3
; AVX1-NEXT: vpalignr {{.*#+}} xmm2 = xmm2[2,3,4,5,6,7,8,9,10,11,12,13,14,15],xmm3[0,1]
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm1[2,3,4,5,6,7,8,9,10,11,12,13,14,15],xmm0[0,1]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_17_18_19_20_21_22_23_00_25_26_27_28_29_30_31_8:
; AVX2: # BB#0:
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm1[2,3,4,5,6,7,8,9,10,11,12,13,14,15],ymm0[0,1],ymm1[18,19,20,21,22,23,24,25,26,27,28,29,30,31],ymm0[16,17]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 00, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30, i32 31, i32 8>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_16_17_18_19_20_21_22_15_24_25_26_27_28_29_30(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_07_16_17_18_19_20_21_22_15_24_25_26_27_28_29_30:
; AVX1: # BB#0:
; AVX1-NEXT: vextractf128 $1, %ymm0, %xmm2
; AVX1-NEXT: vextractf128 $1, %ymm1, %xmm3
; AVX1-NEXT: vpalignr {{.*#+}} xmm2 = xmm2[14,15],xmm3[0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm0[14,15],xmm1[0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vinsertf128 $1, %xmm2, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_07_16_17_18_19_20_21_22_15_24_25_26_27_28_29_30:
; AVX2: # BB#0:
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm0[14,15],ymm1[0,1,2,3,4,5,6,7,8,9,10,11,12,13],ymm0[30,31],ymm1[16,17,18,19,20,21,22,23,24,25,26,27,28,29]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 15, i32 24, i32 25, i32 26, i32 27, i32 28, i32 29, i32 30>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_01_02_03_04_05_06_07_00_17_18_19_20_21_22_23_16(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_01_02_03_04_05_06_07_00_17_18_19_20_21_22_23_16:
; AVX1: # BB#0:
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1]
; AVX1-NEXT: vpalignr {{.*#+}} xmm1 = xmm1[2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_01_02_03_04_05_06_07_00_17_18_19_20_21_22_23_16:
; AVX2: # BB#0:
; AVX2-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm0[2,3,4,5,6,7,8,9,10,11,12,13,14,15,0,1,18,19,20,21,22,23,24,25,26,27,28,29,30,31,16,17]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 0, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22, i32 23, i32 16>
ret <16 x i16> %shuffle
}
define <16 x i16> @shuffle_v16i16_07_00_01_02_03_04_05_06_23_16_17_18_19_20_21_22(<16 x i16> %a, <16 x i16> %b) {
; AVX1-LABEL: shuffle_v16i16_07_00_01_02_03_04_05_06_23_16_17_18_19_20_21_22:
; AVX1: # BB#0:
; AVX1-NEXT: vpalignr {{.*#+}} xmm0 = xmm0[14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vpalignr {{.*#+}} xmm1 = xmm1[14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13]
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: shuffle_v16i16_07_00_01_02_03_04_05_06_23_16_17_18_19_20_21_22:
; AVX2: # BB#0:
; AVX2-NEXT: vinserti128 $1, %xmm1, %ymm0, %ymm0
; AVX2-NEXT: vpalignr {{.*#+}} ymm0 = ymm0[14,15,0,1,2,3,4,5,6,7,8,9,10,11,12,13,30,31,16,17,18,19,20,21,22,23,24,25,26,27,28,29]
; AVX2-NEXT: retq
%shuffle = shufflevector <16 x i16> %a, <16 x i16> %b, <16 x i32> <i32 7, i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 23, i32 16, i32 17, i32 18, i32 19, i32 20, i32 21, i32 22>
ret <16 x i16> %shuffle
}
Reference in New Issue Copy Permalink