RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-31 07:52:55 +01:00
Code Issues Projects Releases Wiki Activity
4a65a2a197
llvm-mirror/test/CodeGen/X86/unaligned-load.ll

38 lines
1.4 KiB
LLVM
Raw Normal View History

Revert r122955. It seems using movups to lower memcpy can cause massive regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. llvm-svn: 123015
2011-01-07 20:35:30 +01:00
; RUN: llc < %s -mtriple=i386-apple-darwin10.0 -mcpu=core2 -relocation-model=dynamic-no-pic --asm-verbose=0 | FileCheck -check-prefix=I386 %s
; RUN: llc < %s -mtriple=x86_64-apple-darwin10.0 -mcpu=core2 -relocation-model=dynamic-no-pic --asm-verbose=0 | FileCheck -check-prefix=CORE2 %s
; RUN: llc < %s -mtriple=x86_64-apple-darwin10.0 -mcpu=corei7 -relocation-model=dynamic-no-pic --asm-verbose=0 | FileCheck -check-prefix=COREI7 %s
Test from Dhrystone to make sure that we're not emitting an aligned load for a string that's aligned at 8-bytes instead of 16-bytes. llvm-svn: 89295
2009-11-19 02:33:57 +01:00
@.str1 = internal constant [31 x i8] c"DHRYSTONE PROGRAM, SOME STRING\00", align 8
@.str3 = internal constant [31 x i8] c"DHRYSTONE PROGRAM, 2'ND STRING\00", align 8
define void @func() nounwind ssp {
entry:
%String2Loc = alloca [31 x i8], align 1
br label %bb
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
bb: ; preds = %bb, %entry
Test from Dhrystone to make sure that we're not emitting an aligned load for a string that's aligned at 8-bytes instead of 16-bytes. llvm-svn: 89295
2009-11-19 02:33:57 +01:00
%String2Loc9 = getelementptr inbounds [31 x i8]* %String2Loc, i64 0, i64 0
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.memcpy.p0i8.p0i8.i64(i8* %String2Loc9, i8* getelementptr inbounds ([31 x i8]* @.str3, i64 0, i64 0), i64 31, i32 1, i1 false)
br label %bb
return: ; No predecessors!
ret void
}
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32, i1) nounwind
Revert r122955. It seems using movups to lower memcpy can cause massive regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. llvm-svn: 123015
2011-01-07 20:35:30 +01:00
; I386: calll {{_?}}memcpy
; CORE2: movabsq
; CORE2: movabsq
; CORE2: movabsq
; COREI7: movups _.str3
Test from Dhrystone to make sure that we're not emitting an aligned load for a string that's aligned at 8-bytes instead of 16-bytes. llvm-svn: 89295
2009-11-19 02:33:57 +01:00
Revert r122955. It seems using movups to lower memcpy can cause massive regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. llvm-svn: 123015
2011-01-07 20:35:30 +01:00
; CORE2: .section
Fix a regression caused by r102515 where explicit alignment on globals is ignored. There was a test to catch this, but it was just blindly updated in a large change. This fixes another part of <rdar://problem/9275290>. llvm-svn: 129466
2011-04-13 22:36:04 +02:00
; CORE2: .align 3
Revert r122955. It seems using movups to lower memcpy can cause massive regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. llvm-svn: 123015
2011-01-07 20:35:30 +01:00
; CORE2-NEXT: _.str1:
; CORE2-NEXT: .asciz "DHRYSTONE PROGRAM, SOME STRING"
Fix a regression caused by r102515 where explicit alignment on globals is ignored. There was a test to catch this, but it was just blindly updated in a large change. This fixes another part of <rdar://problem/9275290>. llvm-svn: 129466
2011-04-13 22:36:04 +02:00
; CORE2: .align 3
Revert r122955. It seems using movups to lower memcpy can cause massive regression (even on Nehalem) in edge cases. I also didn't see any real performance benefit. llvm-svn: 123015
2011-01-07 20:35:30 +01:00
; CORE2-NEXT: _.str3:
Reference in New Issue Copy Permalink