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/alignment-2.ll

31 lines
1.9 KiB
LLVM
Raw Normal View History

Filecheck-ize. llvm-svn: 140904
2011-10-01 07:40:29 +08:00
; RUN: llc < %s -mtriple i386-apple-darwin10 | FileCheck %s
When inferring the pointer alignment, if the global doesn't have an initializer and the alignment is 0 (i.e., it's defined globally in one file and declared in another file) it could get an alignment which is larger than the ABI allows for that type, resulting in aligned moves being used for unaligned loads. For instance, in file A.c: struct S s; In file B.c: struct { // something long }; extern S s; void foo() { struct S p = s; // ... } this copy is a 'memcpy' which is turned into a series of 'movaps' instructions on X86. But this is wrong, because 'struct S' has alignment of 4, not 16. llvm-svn: 140902
2011-10-01 07:19:55 +08:00
; <rdar://problem/10058036>
%struct._psqlSettings = type { %struct.pg_conn*, i32, %struct.__sFILE*, i8, %struct.printQueryOpt, i8*, i8, i32, %struct.__sFILE*, i8, i32, i8*, i8*, i8*, i64, i8, %struct.__sFILE*, %struct._variable*, i8, i8, i8, i8, i8, i32, i32, i32, i32, i32, i8*, i8*, i8*, i32 }
%struct.pg_conn = type opaque
%struct.__sFILE = type { i8*, i32, i32, i16, i16, %struct.__sbuf, i32, i8*, i32 (i8*)*, i32 (i8*, i8*, i32)*, i64 (i8*, i64, i32)*, i32 (i8*, i8*, i32)*, %struct.__sbuf, %struct.__sFILEX*, i32, [3 x i8], [1 x i8], %struct.__sbuf, i32, i64 }
%struct.__sbuf = type { i8*, i32 }
%struct.__sFILEX = type opaque
%struct.printQueryOpt = type { %struct.printTableOpt, i8*, i8, i8*, i8**, i8, i8, i8* }
%struct.printTableOpt = type { i32, i8, i16, i16, i8, i8, i8, i32, %struct.printTextFormat*, i8*, i8*, i8, i8*, i32, i32, i32 }
%struct.printTextFormat = type { i8*, [4 x %struct.printTextLineFormat], i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8 }
%struct.printTextLineFormat = type { i8*, i8*, i8*, i8* }
%struct._variable = type { i8*, i8*, void (i8*)*, %struct._variable* }
%struct.pg_result = type opaque
@pset = external global %struct._psqlSettings
define signext i8 @do_lo_list() nounwind optsize ssp {
bb:
Filecheck-ize. llvm-svn: 140904
2011-10-01 07:40:29 +08:00
; CHECK: do_lo_list
X86: when we are auto-detecting the subtarget features, make sure we turn on FeatureFastUAMem for Nehalem, Westmere and Sandy Bridge. FeatureFastUAMem is already on if we pass in nehalem or westmere as a command argument. rdar: 7252306 llvm-svn: 161717
2012-08-11 07:43:32 +08:00
; Make sure we do not use movaps for the global variable.
; It is okay to use movaps for writing the local variable on stack.
; CHECK-NOT: movaps {{[0-9]*}}(%{{[a-z]*}}), {{%xmm[0-9]}}
When inferring the pointer alignment, if the global doesn't have an initializer and the alignment is 0 (i.e., it's defined globally in one file and declared in another file) it could get an alignment which is larger than the ABI allows for that type, resulting in aligned moves being used for unaligned loads. For instance, in file A.c: struct S s; In file B.c: struct { // something long }; extern S s; void foo() { struct S p = s; // ... } this copy is a 'memcpy' which is turned into a series of 'movaps' instructions on X86. But this is wrong, because 'struct S' has alignment of 4, not 16. llvm-svn: 140902
2011-10-01 07:19:55 +08:00
%myopt = alloca %struct.printQueryOpt, align 4
%tmp = bitcast %struct.printQueryOpt* %myopt to i8*
Revert "Change memcpy/memset/memmove to have dest and source alignments." This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
2015-11-19 13:56:52 +08:00
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %tmp, i8* bitcast (%struct.printQueryOpt* getelementptr inbounds (%struct._psqlSettings, %struct._psqlSettings* @pset, i32 0, i32 4) to i8*), i32 76, i32 4, i1 false)
When inferring the pointer alignment, if the global doesn't have an initializer and the alignment is 0 (i.e., it's defined globally in one file and declared in another file) it could get an alignment which is larger than the ABI allows for that type, resulting in aligned moves being used for unaligned loads. For instance, in file A.c: struct S s; In file B.c: struct { // something long }; extern S s; void foo() { struct S p = s; // ... } this copy is a 'memcpy' which is turned into a series of 'movaps' instructions on X86. But this is wrong, because 'struct S' has alignment of 4, not 16. llvm-svn: 140902
2011-10-01 07:19:55 +08:00
ret i8 0
}
Revert "Change memcpy/memset/memmove to have dest and source alignments." This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
2015-11-19 13:56:52 +08:00
declare void @llvm.memcpy.p0i8.p0i8.i32(i8* nocapture, i8* nocapture, i32, i32, i1) nounwind