6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-16 11:30:51 +00:00
Code Issues Projects Releases Wiki Activity
dc0ca89635
llvm-6502/test/CodeGen/X86/vector-sext.ll

810 lines
26 KiB
LLVM
Raw Normal View History

[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mattr=+sse2 | FileCheck %s --check-prefix=SSE --check-prefix=SSE2
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mattr=+ssse3 | FileCheck %s --check-prefix=SSE --check-prefix=SSSE3
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mattr=+sse4.1 | FileCheck %s --check-prefix=SSE --check-prefix=SSE41
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mattr=+avx | FileCheck %s --check-prefix=AVX --check-prefix=AVX1
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mcpu=x86-64 -mattr=+avx2 | FileCheck %s --check-prefix=AVX --check-prefix=AVX2
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; Just one 32-bit run to make sure we do reasonable things there.
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; RUN: llc < %s -mtriple=i686-unknown-unknown -mcpu=i686 -mattr=+sse4.1 | FileCheck %s --check-prefix=X32-SSE41
Optimization for SIGN_EXTEND operation on AVX. Special handling was added for v4i32 -> v4i64 and v8i16 -> v8i32 extensions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149600 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-02 09:10:43 +00:00
define <8 x i32> @sext_8i16_to_8i32(<8 x i16> %A) nounwind uwtable readnone ssp {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movdqa %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: # kill: XMM0<def> XMM1<kill>
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
; SSE2-NEXT: pslld $16, %xmm0
; SSE2-NEXT: psrad $16, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4,4,5,5,6,6,7,7]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: pslld $16, %xmm1
; SSE2-NEXT: psrad $16, %xmm1
; SSE2-NEXT: retq
;
; SSSE3-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movdqa %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: # kill: XMM0<def> XMM1<kill>
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
; SSSE3-NEXT: pslld $16, %xmm0
; SSSE3-NEXT: psrad $16, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4,4,5,5,6,6,7,7]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: pslld $16, %xmm1
; SSSE3-NEXT: psrad $16, %xmm1
; SSSE3-NEXT: retq
;
; SSE41-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: movdqa %xmm0, %xmm1
; SSE41-NEXT: pmovzxwd %xmm1, %xmm0
; SSE41-NEXT: pslld $16, %xmm0
; SSE41-NEXT: psrad $16, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE41-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4,4,5,5,6,6,7,7]
; SSE41-NEXT: pslld $16, %xmm1
; SSE41-NEXT: psrad $16, %xmm1
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxwd %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxwd %xmm0, %xmm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpmovsxwd %xmm0, %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: sext_8i16_to_8i32:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movdqa %xmm0, %xmm1
; X32-SSE41-NEXT: pmovzxwd %xmm1, %xmm0
; X32-SSE41-NEXT: pslld $16, %xmm0
; X32-SSE41-NEXT: psrad $16, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; X32-SSE41-NEXT: punpckhwd {{.*#+}} xmm1 = xmm1[4,4,5,5,6,6,7,7]
; X32-SSE41-NEXT: pslld $16, %xmm1
; X32-SSE41-NEXT: psrad $16, %xmm1
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
%B = sext <8 x i16> %A to <8 x i32>
ret <8 x i32>%B
}
define <4 x i64> @sext_4i32_to_4i64(<4 x i32> %A) nounwind uwtable readnone ssp {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSE2-NEXT: movdqa %xmm2, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSSE3-NEXT: movdqa %xmm2, %xmm0
; SSSE3-NEXT: retq
;
; SSE41-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovzxdq %xmm0, %xmm1
; SSE41-NEXT: pextrq $1, %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm2
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pextrq $1, %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm1
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm3[0]
; SSE41-NEXT: movdqa %xmm2, %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpmovsxdq %xmm0, %ymm0
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: sext_4i32_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: pmovzxdq %xmm0, %xmm2
; X32-SSE41-NEXT: movd %xmm2, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm2, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm2
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; X32-SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,2,3,3]
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movd %xmm1, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm1, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm1
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm1
; X32-SSE41-NEXT: movdqa %xmm2, %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
Optimization for SIGN_EXTEND operation on AVX. Special handling was added for v4i32 -> v4i64 and v8i16 -> v8i32 extensions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149600 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-02 09:10:43 +00:00
%B = sext <4 x i32> %A to <4 x i64>
ret <4 x i64>%B
}
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
define <4 x i32> @load_sext_test1(<4 x i16> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_test1:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movq (%rdi), %xmm0
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
; SSE2-NEXT: psrad $16, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_test1:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movq (%rdi), %xmm0
; SSSE3-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
; SSSE3-NEXT: psrad $16, %xmm0
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_test1:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxwd (%rdi), %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX-LABEL: load_sext_test1:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxwd (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test1:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxwd (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <4 x i16>, <4 x i16>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <4 x i16> %X to <4 x i32>
ret <4 x i32>%Y
}
define <4 x i32> @load_sext_test2(<4 x i8> *%ptr) {
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-LABEL: load_sext_test2:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: movd (%rdi), %xmm0
; SSE2-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-NEXT: psrad $24, %xmm0
; SSE2-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; SSSE3-LABEL: load_sext_test2:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; SSSE3-NEXT: movd (%rdi), %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSSE3-NEXT: punpcklwd {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3]
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; SSSE3-NEXT: psrad $24, %xmm0
; SSSE3-NEXT: retq
;
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-LABEL: load_sext_test2:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxbd (%rdi), %xmm0
; SSE41-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-LABEL: load_sext_test2:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxbd (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test2:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxbd (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <4 x i8>, <4 x i8>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <4 x i8> %X to <4 x i32>
ret <4 x i32>%Y
}
define <2 x i64> @load_sext_test3(<2 x i8> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_test3:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movsbq 1(%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: movsbq (%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_test3:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movsbq 1(%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: movsbq (%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_test3:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxbq (%rdi), %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX-LABEL: load_sext_test3:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxbq (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test3:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxbq (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <2 x i8>, <2 x i8>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <2 x i8> %X to <2 x i64>
ret <2 x i64>%Y
}
define <2 x i64> @load_sext_test4(<2 x i16> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_test4:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movswq 2(%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: movswq (%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_test4:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movswq 2(%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: movswq (%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_test4:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxwq (%rdi), %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX-LABEL: load_sext_test4:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxwq (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test4:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxwq (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <2 x i16>, <2 x i16>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <2 x i16> %X to <2 x i64>
ret <2 x i64>%Y
}
define <2 x i64> @load_sext_test5(<2 x i32> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_test5:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movslq 4(%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: movslq (%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_test5:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movslq 4(%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: movslq (%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_test5:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxdq (%rdi), %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX-LABEL: load_sext_test5:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxdq (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test5:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxdq (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <2 x i32>, <2 x i32>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <2 x i32> %X to <2 x i64>
ret <2 x i64>%Y
}
define <8 x i16> @load_sext_test6(<8 x i8> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_test6:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movq (%rdi), %xmm0
; SSE2-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: psraw $8, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_test6:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movq (%rdi), %xmm0
; SSSE3-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSSE3-NEXT: psraw $8, %xmm0
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_test6:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pmovsxbw (%rdi), %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX-LABEL: load_sext_test6:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX-NEXT: vpmovsxbw (%rdi), %xmm0
; AVX-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_test6:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-SSE41-NEXT: pmovsxbw (%eax), %xmm0
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <8 x i8>, <8 x i8>* %ptr
Optimized load + SIGN_EXTEND patterns in the X86 backend. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170506 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-19 07:50:20 +00:00
%Y = sext <8 x i8> %X to <8 x i16>
ret <8 x i16>%Y
}
I optimized the following patterns: sext <4 x i1> to <4 x i64> sext <4 x i8> to <4 x i64> sext <4 x i16> to <4 x i64> I'm running Combine on SIGN_EXTEND_IN_REG and revert SEXT patterns: (sext_in_reg (v4i64 anyext (v4i32 x )), ExtraVT) -> (v4i64 sext (v4i32 sext_in_reg (v4i32 x , ExtraVT))) The sext_in_reg (v4i32 x) may be lowered to shl+sar operations. The "sar" does not exist on 64-bit operation, so lowering sext_in_reg (v4i64 x) has no vector solution. I also added a cost of this operations to the AVX costs table. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175619 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-20 12:42:54 +00:00
define <4 x i64> @sext_4i1_to_4i64(<4 x i1> %mask) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: pslld $31, %xmm0
; SSE2-NEXT: psrad $31, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSE2-NEXT: movdqa %xmm2, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: pslld $31, %xmm0
; SSSE3-NEXT: psrad $31, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSSE3-NEXT: movdqa %xmm2, %xmm0
; SSSE3-NEXT: retq
;
; SSE41-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pslld $31, %xmm0
; SSE41-NEXT: psrad $31, %xmm0
; SSE41-NEXT: pmovzxdq %xmm0, %xmm1
; SSE41-NEXT: pextrq $1, %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm2
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pextrq $1, %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm1
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm3[0]
; SSE41-NEXT: movdqa %xmm2, %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0:
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpslld $31, %xmm0, %xmm0
; AVX1-NEXT: vpsrad $31, %xmm0, %xmm0
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0:
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpslld $31, %xmm0, %xmm0
; AVX2-NEXT: vpsrad $31, %xmm0, %xmm0
; AVX2-NEXT: vpmovsxdq %xmm0, %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: sext_4i1_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0:
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: pslld $31, %xmm0
; X32-SSE41-NEXT: psrad $31, %xmm0
; X32-SSE41-NEXT: pmovzxdq %xmm0, %xmm2
; X32-SSE41-NEXT: movd %xmm2, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm2, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm2
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; X32-SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,2,3,3]
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movd %xmm1, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm1, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm1
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm1
; X32-SSE41-NEXT: movdqa %xmm2, %xmm0
; X32-SSE41-NEXT: retl
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
%extmask = sext <4 x i1> %mask to <4 x i64>
ret <4 x i64> %extmask
}
define <16 x i16> @sext_16i8_to_16i16(<16 x i8> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movq (%rdi), %xmm0
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSE2-NEXT: psraw $8, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movq 8(%rdi), %xmm1
; SSE2-NEXT: punpcklbw {{.*#+}} xmm1 = xmm1[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: psraw $8, %xmm1
; SSE2-NEXT: retq
;
; SSSE3-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movq (%rdi), %xmm0
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: punpcklbw {{.*#+}} xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
; SSSE3-NEXT: psraw $8, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movq 8(%rdi), %xmm1
; SSSE3-NEXT: punpcklbw {{.*#+}} xmm1 = xmm1[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: psraw $8, %xmm1
; SSSE3-NEXT: retq
;
; SSE41-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE41-NEXT: pmovsxbw (%rdi), %xmm0
; SSE41-NEXT: pmovsxbw 8(%rdi), %xmm1
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; AVX1-NEXT: vpmovsxbw (%rdi), %xmm0
; AVX1-NEXT: vpmovsxbw 8(%rdi), %xmm1
; AVX1-NEXT: vinsertf128 $1, %xmm1, %ymm0, %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0: # %entry
[X86] Refactor PMOV[SZ]Xrm to add missing AVX2 patterns. Most patterns will go away once the extload legalization changes land. Differential Revision: http://reviews.llvm.org/D6125 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223567 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-06 01:31:07 +00:00
; AVX2-NEXT: vpmovsxbw (%rdi), %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: sext_16i8_to_16i16:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; X32-SSE41-NEXT: pmovsxbw (%eax), %xmm0
; X32-SSE41-NEXT: pmovsxbw 8(%eax), %xmm1
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <16 x i8>, <16 x i8>* %ptr
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
%Y = sext <16 x i8> %X to <16 x i16>
ret <16 x i16> %Y
}
define <4 x i64> @sext_4i8_to_4i64(<4 x i8> %mask) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: pslld $24, %xmm0
; SSE2-NEXT: psrad $24, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm1, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE2-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %xmm0, %rax
; SSE2-NEXT: cltq
; SSE2-NEXT: movd %rax, %xmm0
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSE2-NEXT: movdqa %xmm2, %xmm0
; SSE2-NEXT: retq
;
; SSSE3-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: pslld $24, %xmm0
; SSSE3-NEXT: psrad $24, %xmm0
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm0[0,1,1,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm1 = xmm1[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm1, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm1[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSSE3-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %xmm0, %rax
; SSSE3-NEXT: cltq
; SSSE3-NEXT: movd %rax, %xmm0
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm0[0]
; SSSE3-NEXT: movdqa %xmm2, %xmm0
; SSSE3-NEXT: retq
;
; SSE41-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0:
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pslld $24, %xmm0
; SSE41-NEXT: psrad $24, %xmm0
; SSE41-NEXT: pmovzxdq %xmm0, %xmm1
; SSE41-NEXT: pextrq $1, %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm1, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm2
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm2 = xmm2[0],xmm3[0]
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; SSE41-NEXT: pshufd {{.*#+}} xmm0 = xmm0[2,2,3,3]
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: pextrq $1, %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm3
; SSE41-NEXT: movd %xmm0, %rax
; SSE41-NEXT: cltq
; SSE41-NEXT: movd %rax, %xmm1
; SSE41-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm3[0]
; SSE41-NEXT: movdqa %xmm2, %xmm0
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0:
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpslld $24, %xmm0, %xmm0
; AVX1-NEXT: vpsrad $24, %xmm0, %xmm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0:
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpslld $24, %xmm0, %xmm0
; AVX2-NEXT: vpsrad $24, %xmm0, %xmm0
; AVX2-NEXT: vpmovsxdq %xmm0, %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0:
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: pslld $24, %xmm0
; X32-SSE41-NEXT: psrad $24, %xmm0
; X32-SSE41-NEXT: pmovzxdq %xmm0, %xmm2
; X32-SSE41-NEXT: movd %xmm2, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm2, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm2
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm2
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; X32-SSE41-NEXT: pshufd {{.*#+}} xmm1 = xmm0[2,2,3,3]
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movd %xmm1, %eax
; X32-SSE41-NEXT: sarl $31, %eax
; X32-SSE41-NEXT: pextrd $2, %xmm1, %ecx
; X32-SSE41-NEXT: pinsrd $1, %eax, %xmm1
; X32-SSE41-NEXT: sarl $31, %ecx
; X32-SSE41-NEXT: pinsrd $3, %ecx, %xmm1
; X32-SSE41-NEXT: movdqa %xmm2, %xmm0
; X32-SSE41-NEXT: retl
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
%extmask = sext <4 x i8> %mask to <4 x i64>
ret <4 x i64> %extmask
}
define <4 x i64> @load_sext_4i8_to_4i64(<4 x i8> *%ptr) {
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movsbq 1(%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: movsbq (%rdi), %rax
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-NEXT: movd %rax, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: movsbq 3(%rdi), %rax
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-NEXT: movd %rax, %xmm2
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movsbq 2(%rdi), %rax
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; SSSE3-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movsbq 1(%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: movsbq (%rdi), %rax
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; SSSE3-NEXT: movd %rax, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSSE3-NEXT: movsbq 3(%rdi), %rax
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; SSSE3-NEXT: movd %rax, %xmm2
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movsbq 2(%rdi), %rax
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSSE3-NEXT: retq
;
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE41-NEXT: pmovsxbq (%rdi), %xmm0
; SSE41-NEXT: pmovsxbq 2(%rdi), %xmm1
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxbd (%rdi), %xmm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpmovsxbq (%rdi), %ymm0
[x86] Clean up and generate detailed FileCheck assertions for avx-sext.ll using my new script. Also add an AVX2 mode to this test. Part of cleaning up the test suite before enabling the new vector shuffle lowering. This also highlights some of the abysmal failures of the old shuffle lowering. Check out those 'pinsrw' and 'pextrw' sequences! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218794 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:19:32 +00:00
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_4i8_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; X32-SSE41-NEXT: pmovsxbq (%eax), %xmm0
; X32-SSE41-NEXT: pmovsxbq 2(%eax), %xmm1
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <4 x i8>, <4 x i8>* %ptr
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
%Y = sext <4 x i8> %X to <4 x i64>
ret <4 x i64>%Y
}
define <4 x i64> @load_sext_4i16_to_4i64(<4 x i16> *%ptr) {
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE2: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movswq 2(%rdi), %rax
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: movswq (%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %rax, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSE2-NEXT: movswq 6(%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %rax, %xmm2
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE2-NEXT: movswq 4(%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE2-NEXT: movd %rax, %xmm1
; SSE2-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSE2-NEXT: retq
;
; SSSE3-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSSE3: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movswq 2(%rdi), %rax
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: movswq (%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %rax, %xmm0
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm0 = xmm0[0],xmm1[0]
; SSSE3-NEXT: movswq 6(%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %rax, %xmm2
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSSE3-NEXT: movswq 4(%rdi), %rax
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSSE3-NEXT: movd %rax, %xmm1
; SSSE3-NEXT: punpcklqdq {{.*#+}} xmm1 = xmm1[0],xmm2[0]
; SSSE3-NEXT: retq
;
; SSE41-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; SSE41: # BB#0: # %entry
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; SSE41-NEXT: pmovsxwq (%rdi), %xmm0
; SSE41-NEXT: pmovsxwq 4(%rdi), %xmm1
[x86] Teach both sext and zext vector tests to cover a nice wide range of architectures: SSE2, SSSE3, SSE4.1, AVX, and AVX2. Unfortunately, this exposses the absolute horror of the code we generate for many of these patterns. Anyone wanting to familiarize themselves with the x86 backend and improve performance could do a lot of good sitting down and making these test cases not look so terrible. While the new vector shuffle code I'm working on well help some, it won't fix all of the crimes here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218807 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:41:36 +00:00
; SSE41-NEXT: retq
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
;
; AVX1-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX1: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxwd (%rdi), %xmm0
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm1
[x86] Enable the new vector shuffle lowering by default. Update the entire regression test suite for the new shuffles. Remove most of the old testing which was devoted to the old shuffle lowering path and is no longer relevant really. Also remove a few other random tests that only really exercised shuffles and only incidently or without any interesting aspects to them. Benchmarking that I have done shows a few small regressions with this on LNT, zero measurable regressions on real, large applications, and for several benchmarks where the loop vectorizer fires in the hot path it shows 5% to 40% improvements for SSE2 and SSE3 code running on Sandy Bridge machines. Running on AMD machines shows even more dramatic improvements. When using newer ISA vector extensions the gains are much more modest, but the code is still better on the whole. There are a few regressions being tracked (PR21137, PR21138, PR21139) but by and large this is expected to be a win for x86 generated code performance. It is also more correct than the code it replaces. I have fuzz tested this extensively with ISA extensions up through AVX2 and found no crashes or miscompiles (yet...). The old lowering had a few miscompiles and crashers after a somewhat smaller amount of fuzz testing. There is one significant area where the new code path lags behind and that is in AVX-512 support. However, there was *extremely little* support for that already and so this isn't a significant step backwards and the new framework will probably make it easier to implement lowering that uses the full power of AVX-512's table-based shuffle+blend (IMO). Many thanks to Quentin, Andrea, Robert, and others for benchmarking assistance. Thanks to Adam and others for help with AVX-512. Thanks to Hal, Eric, and *many* others for answering my incessant questions about how the backend actually works. =] I will leave the old code path in the tree until the 3 PRs above are at least resolved to folks' satisfaction. Then I will rip it (and 1000s of lines of code) out. =] I don't expect this flag to stay around for very long. It may not survive next week. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219046 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-04 03:52:55 +00:00
; AVX1-NEXT: vpshufd {{.*#+}} xmm0 = xmm0[2,3,0,1]
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX1-NEXT: vpmovsxdq %xmm0, %xmm0
; AVX1-NEXT: vinsertf128 $1, %xmm0, %ymm1, %ymm0
; AVX1-NEXT: retq
;
; AVX2-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; AVX2: # BB#0: # %entry
[x86] Sort the ISA-specific RUN lines for vector-sext.ll to go from oldest to newest. This makes more sense to me and is more consistent with other tests. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218802 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:32:44 +00:00
; AVX2-NEXT: vpmovsxwq (%rdi), %ymm0
; AVX2-NEXT: retq
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
;
; X32-SSE41-LABEL: load_sext_4i16_to_4i64:
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
; X32-SSE41: # BB#0: # %entry
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: movl {{[0-9]+}}(%esp), %eax
[CodeGen] Add hook/combine to form vector extloads, enabled on X86. The combine that forms extloads used to be disabled on vector types, because "None of the supported targets knows how to perform load and sign extend on vectors in one instruction." That's not entirely true, since at least SSE4.1 X86 knows how to do those sextloads/zextloads (with PMOVS/ZX). But there are several aspects to getting this right. First, vector extloads are controlled by a profitability callback. For instance, on ARM, several instructions have folded extload forms, so it's not always beneficial to create an extload node (and trying to match extloads is a whole 'nother can of worms). The interesting optimization enables folding of s/zextloads to illegal (splittable) vector types, expanding them into smaller legal extloads. It's not ideal (it introduces some legalization-like behavior in the combine) but it's better than the obvious alternative: form illegal extloads, and later try to split them up. If you do that, you might generate extloads that can't be split up, but have a valid ext+load expansion. At vector-op legalization time, it's too late to generate this kind of code, so you end up forced to scalarize. It's better to just avoid creating egregiously illegal nodes. This optimization is enabled unconditionally on X86. Note that the splitting combine is happy with "custom" extloads. As is, this bypasses the actual custom lowering, and just unrolls the extload. But from what I've seen, this is still much better than the current custom lowering, which does some kind of unrolling at the end anyway (see for instance load_sext_4i8_to_4i64 on SSE2, and the added FIXME). Also note that the existing combine that forms extloads is now also enabled on legal vectors. This doesn't have a big effect on X86 (because sext+load is usually combined to sext_inreg+aextload). On ARM it fires on some rare occasions; that's for a separate commit. Differential Revision: http://reviews.llvm.org/D6904 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228325 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 18:31:02 +00:00
; X32-SSE41-NEXT: pmovsxwq (%eax), %xmm0
; X32-SSE41-NEXT: pmovsxwq 4(%eax), %xmm1
[x86] Add a 32-bit run to the sext test, and remove a sad vec_sext.ll test file. This old test had a bunch of functions that were never even checked. =/ The only thing it really did was to make sure that we did something reasonable in 32-bit mode with SSE4.1. Adding another run line to the main vector-sext.ll test seems a better way to do that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218810 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 20:49:54 +00:00
; X32-SSE41-NEXT: retl
[x86] Switch some of the new consolidated vector tests to use a bare-metal triple and have nice BB labels, etc. No significant change here, just tidying up to have a consistent set of OS-agnostic vector functionality here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218854 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 06:52:19 +00:00
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230794 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-27 21:17:42 +00:00
%X = load <4 x i16>, <4 x i16>* %ptr
Optimize sext <4 x i8> and <4 x i16> to <4 x i64>. Patch by Ahmad, Muhammad T <muhammad.t.ahmad@intel.com> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177421 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-19 18:38:27 +00:00
%Y = sext <4 x i16> %X to <4 x i64>
ret <4 x i64>%Y
}
Reference in New Issue Copy Permalink