maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/i64-mem-copy.ll

79 lines
2.5 KiB
LLVM
Raw Normal View History

use update_llc_test_checks.py to tighten checking Also, replace win and linux runs with a generic run because that makes no difference in what this test is checking. llvm-svn: 235361
2015-04-21 07:31:53 +08:00
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=sse2 | FileCheck %s --check-prefix=X64
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=sse2 | FileCheck %s --check-prefix=X32
[x86] allow 64-bit extracted vector element integer stores on a 32-bit system With SSE2, we can generate a 'movq' or other 64-bit store op on a 32-bit system even though 64-bit integers are not legal types. So instead of producing this: pshufd $229, %xmm0, %xmm1 ## xmm1 = xmm0[1,1,2,3] movd %xmm0, (%eax) movd %xmm1, 4(%eax) We can do: movq %xmm0, (%eax) This is a fix for the problem noted in D7296. Differential Revision: http://reviews.llvm.org/D9134 llvm-svn: 235460
2015-04-22 08:24:30 +08:00
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=avx2 | FileCheck %s --check-prefix=X32AVX
On x86, if the only use of a i64 load is a i64 store, generate a pair of double load and store instead. llvm-svn: 66776
2009-03-12 13:59:15 +08:00
use update_llc_test_checks.py to tighten checking Also, replace win and linux runs with a generic run because that makes no difference in what this test is checking. llvm-svn: 235361
2015-04-21 07:31:53 +08:00
; Use movq or movsd to load / store i64 values if sse2 is available.
On x86, if the only use of a i64 load is a i64 store, generate a pair of double load and store instead. llvm-svn: 66776
2009-03-12 13:59:15 +08:00
; rdar://6659858
use update_llc_test_checks.py to tighten checking Also, replace win and linux runs with a generic run because that makes no difference in what this test is checking. llvm-svn: 235361
2015-04-21 07:31:53 +08:00
define void @foo(i64* %x, i64* %y) {
; X64-LABEL: foo:
; X64: # BB#0:
; X64-NEXT: movq (%rsi), %rax
; X64-NEXT: movq %rax, (%rdi)
; X64-NEXT: retq
;
; X32-LABEL: foo:
; X32: # BB#0:
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; X32-NEXT: movsd %xmm0, (%eax)
; X32-NEXT: retl
%tmp1 = load i64, i64* %y, align 8
store i64 %tmp1, i64* %x, align 8
ret void
On x86, if the only use of a i64 load is a i64 store, generate a pair of double load and store instead. llvm-svn: 66776
2009-03-12 13:59:15 +08:00
}
use update_llc_test_checks.py to tighten checking Also, replace win and linux runs with a generic run because that makes no difference in what this test is checking. llvm-svn: 235361
2015-04-21 07:31:53 +08:00
[x86] allow 64-bit extracted vector element integer stores on a 32-bit system With SSE2, we can generate a 'movq' or other 64-bit store op on a 32-bit system even though 64-bit integers are not legal types. So instead of producing this: pshufd $229, %xmm0, %xmm1 ## xmm1 = xmm0[1,1,2,3] movd %xmm0, (%eax) movd %xmm1, 4(%eax) We can do: movq %xmm0, (%eax) This is a fix for the problem noted in D7296. Differential Revision: http://reviews.llvm.org/D9134 llvm-svn: 235460
2015-04-22 08:24:30 +08:00
; Verify that a 64-bit chunk extracted from a vector is stored with a movq
; regardless of whether the system is 64-bit.
define void @store_i64_from_vector(<8 x i16> %x, <8 x i16> %y, i64* %i) {
; X64-LABEL: store_i64_from_vector:
; X64: # BB#0:
; X64-NEXT: paddw %xmm1, %xmm0
; X64-NEXT: movq %xmm0, (%rdi)
; X64-NEXT: retq
;
; X32-LABEL: store_i64_from_vector:
; X32: # BB#0:
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NEXT: paddw %xmm1, %xmm0
; X32-NEXT: movq %xmm0, (%eax)
; X32-NEXT: retl
%z = add <8 x i16> %x, %y ; force execution domain
%bc = bitcast <8 x i16> %z to <2 x i64>
%vecext = extractelement <2 x i64> %bc, i32 0
store i64 %vecext, i64* %i, align 8
ret void
}
define void @store_i64_from_vector256(<16 x i16> %x, <16 x i16> %y, i64* %i) {
; X32AVX-LABEL: store_i64_from_vector256:
; X32AVX: # BB#0:
; X32AVX-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32AVX-NEXT: vpaddw %ymm1, %ymm0, %ymm0
; X32AVX-NEXT: vextracti128 $1, %ymm0, %xmm0
; X32AVX-NEXT: vmovq %xmm0, (%eax)
; X32AVX-NEXT: vzeroupper
; X32AVX-NEXT: retl
%z = add <16 x i16> %x, %y ; force execution domain
%bc = bitcast <16 x i16> %z to <4 x i64>
%vecext = extractelement <4 x i64> %bc, i32 2
store i64 %vecext, i64* %i, align 8
ret void
}
[X86] DAGCombine should not assume arbitrary vector types are simple The X86-specific DAGCombine for stores should not assume vector types are always simple. This fixes PR23476. Differential Revision: http://reviews.llvm.org/D9659 llvm-svn: 237097
2015-05-12 15:33:07 +08:00
; PR23476
; Handle extraction from a non-simple / pre-legalization type.
define void @PR23476(<5 x i64> %in, i64* %out, i32 %index) {
; X32-LABEL: PR23476:
DAG: Avoid OOB when legalizing vector indexing If a vector index is out of bounds, the result is supposed to be undefined but is not undefined behavior. Change the legalization for indexing the vector on the stack so that an out of bounds index does not create an out of bounds memory access. llvm-svn: 291604
2017-01-11 06:02:30 +08:00
; X32: andl $7, %eax
[X86] DAGCombine should not assume arbitrary vector types are simple The X86-specific DAGCombine for stores should not assume vector types are always simple. This fixes PR23476. Differential Revision: http://reviews.llvm.org/D9659 llvm-svn: 237097
2015-05-12 15:33:07 +08:00
; X32: movsd {{.*#+}} xmm0 = mem[0],zero
[X86][SSE] Fix domains for VZEXT_LOAD type instructions Add the missing domain equivalences for movss, movsd, movd and movq zero extending loading instructions. Differential Revision: https://reviews.llvm.org/D27684 llvm-svn: 289825
2016-12-16 00:05:29 +08:00
; X32: movsd {{.*#+}} xmm0 = mem[0],zero
DAG: Avoid OOB when legalizing vector indexing If a vector index is out of bounds, the result is supposed to be undefined but is not undefined behavior. Change the legalization for indexing the vector on the stack so that an out of bounds index does not create an out of bounds memory access. llvm-svn: 291604
2017-01-11 06:02:30 +08:00
; X32-NEXT: movsd %xmm0, (%ecx)
[X86] DAGCombine should not assume arbitrary vector types are simple The X86-specific DAGCombine for stores should not assume vector types are always simple. This fixes PR23476. Differential Revision: http://reviews.llvm.org/D9659 llvm-svn: 237097
2015-05-12 15:33:07 +08:00
%ext = extractelement <5 x i64> %in, i32 %index
store i64 %ext, i64* %out, align 8
ret void
}