RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-29 23:12:55 +01:00
Code Issues Projects Releases Wiki Activity
384eb1e0f0
llvm-mirror/test/CodeGen/X86/memset.ll

56 lines
1.5 KiB
LLVM
Raw Normal View History

llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
; RUN: llc < %s -march=x86 -mcpu=pentium2 -mtriple=i686-apple-darwin8.8.0 | FileCheck %s --check-prefix=X86
; RUN: llc < %s -march=x86 -mcpu=pentium3 -mtriple=i686-apple-darwin8.8.0 | FileCheck %s --check-prefix=XMM
; RUN: llc < %s -march=x86 -mcpu=bdver1 -mtriple=i686-apple-darwin8.8.0 | FileCheck %s --check-prefix=YMM
Add a couple of test cases. llvm-svn: 51441
2008-05-22 23:19:19 +02:00
%struct.x = type { i16, i16 }
define void @t() nounwind {
entry:
%up_mvd = alloca [8 x %struct.x] ; <[8 x %struct.x]*> [#uses=2]
%up_mvd116 = getelementptr [8 x %struct.x]* %up_mvd, i32 0, i32 0 ; <%struct.x*> [#uses=1]
%tmp110117 = bitcast [8 x %struct.x]* %up_mvd to i8* ; <i8*> [#uses=1]
llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
rip out a ton of intrinsic modernization logic from AutoUpgrade.cpp, which is for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the target indep prefetch change. As usual, updating the testsuite is a PITA. llvm-svn: 133337
2011-06-18 08:05:24 +02:00
call void @llvm.memset.p0i8.i64(i8* %tmp110117, i8 0, i64 32, i32 8, i1 false)
llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86: movl $0,
; X86-NOT: movl $0,
Fix the root cause of PR15348 by correctly handling alignment 0 on memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. llvm-svn: 176022
2013-02-25 15:20:21 +01:00
; X86: ret
llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
; XMM: xorps %xmm{{[0-9]+}}, [[Z:%xmm[0-9]+]]
; XMM: movaps [[Z]],
; XMM: movaps [[Z]],
; XMM-NOT: movaps
Fix the root cause of PR15348 by correctly handling alignment 0 on memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. llvm-svn: 176022
2013-02-25 15:20:21 +01:00
; XMM: ret
llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
; YMM: vxorps %ymm{{[0-9]+}}, %ymm{{[0-9]+}}, [[Z:%ymm[0-9]+]]
; YMM: vmovaps [[Z]],
; YMM-NOT: movaps
Fix the root cause of PR15348 by correctly handling alignment 0 on memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. llvm-svn: 176022
2013-02-25 15:20:21 +01:00
; YMM: ret
llvm/test/CodeGen/X86/memset.ll: FileCheck-ize, and add another case on +avx. llvm-svn: 167975
2012-11-14 22:01:40 +01:00
Add a couple of test cases. llvm-svn: 51441
2008-05-22 23:19:19 +02:00
call void @foo( %struct.x* %up_mvd116 ) nounwind
ret void
}
declare void @foo(%struct.x*)
rip out a ton of intrinsic modernization logic from AutoUpgrade.cpp, which is for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the target indep prefetch change. As usual, updating the testsuite is a PITA. llvm-svn: 133337
2011-06-18 08:05:24 +02:00
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind
Fix the root cause of PR15348 by correctly handling alignment 0 on memory intrinsics in the SDAG builder. When alignment is zero, the lang ref says that *no* alignment assumptions can be made. This is the exact opposite of the internal API contracts of the DAG where alignment 0 indicates that the alignment can be made to be anything desired. There is another, more explicit alignment that is better suited for the role of "no alignment at all": an alignment of 1. Map the intrinsic alignment to this early so that we don't end up generating aligned DAGs. It is really terrifying that we've never seen this before, but we suddenly started generating a large number of alignment 0 memcpys due to the new code to do memcpy-based copying of POD class members. That patch contains a bug that rounds bitfield alignments down when they are the first field. This can in turn produce zero alignments. This fixes weird crashes I've seen in library users of LLVM on 32-bit hosts, etc. llvm-svn: 176022
2013-02-25 15:20:21 +01:00
define void @PR15348(i8* %a) {
; Ensure that alignment of '0' in an @llvm.memset intrinsic results in
; unaligned loads and stores.
; XMM: PR15348
; XMM: movb $0,
; XMM: movl $0,
; XMM: movl $0,
; XMM: movl $0,
; XMM: movl $0,
call void @llvm.memset.p0i8.i64(i8* %a, i8 0, i64 17, i32 0, i1 false)
ret void
}
Reference in New Issue Copy Permalink