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

78 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:
; 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
[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-NEXT: movsd %xmm0, (%eax)
%ext = extractelement <5 x i64> %in, i32 %index
store i64 %ext, i64* %out, align 8
ret void
}