maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/MemCpyOpt/align.ll

38 lines
1.3 KiB
LLVM
Raw Normal View History

The memcpy optimizer was happily doing call slot forwarding when the new memory was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
2012-10-04 18:54:40 +08:00
; RUN: opt < %s -S -basicaa -memcpyopt | FileCheck %s
Make opt default to not adding a target data string and update tests that depend on target data to supply it within the test llvm-svn: 85900
2009-11-03 23:29:06 +08:00
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64"
When extending a memset range past the front, set the alignment of the memset region to the alignment of the new start address. llvm-svn: 81810
2009-09-15 07:39:10 +08:00
The memcpy optimizer was happily doing call slot forwarding when the new memory was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
2012-10-04 18:54:40 +08:00
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32, i1) nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind
When extending a memset range past the front, set the alignment of the memset region to the alignment of the new start address. llvm-svn: 81810
2009-09-15 07:39:10 +08:00
; The resulting memset is only 4-byte aligned, despite containing
fix typo llvm-svn: 123148
2011-01-10 10:33:34 +08:00
; a 16-byte aligned store in the middle.
When extending a memset range past the front, set the alignment of the memset region to the alignment of the new start address. llvm-svn: 81810
2009-09-15 07:39:10 +08:00
define void @foo(i32* %p) {
Update Transforms tests to use CHECK-LABEL for easier debugging. No functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
2013-07-14 09:42:54 +08:00
; CHECK-LABEL: @foo(
The memcpy optimizer was happily doing call slot forwarding when the new memory was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
2012-10-04 18:54:40 +08:00
; CHECK: call void @llvm.memset.p0i8.i64(i8* {{.*}}, i8 0, i64 16, i32 4, i1 false)
When extending a memset range past the front, set the alignment of the memset region to the alignment of the new start address. llvm-svn: 81810
2009-09-15 07:39:10 +08:00
%a0 = getelementptr i32* %p, i64 0
store i32 0, i32* %a0, align 4
%a1 = getelementptr i32* %p, i64 1
store i32 0, i32* %a1, align 16
%a2 = getelementptr i32* %p, i64 2
store i32 0, i32* %a2, align 4
%a3 = getelementptr i32* %p, i64 3
store i32 0, i32* %a3, align 4
ret void
}
The memcpy optimizer was happily doing call slot forwarding when the new memory was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
2012-10-04 18:54:40 +08:00
; Replacing %a8 with %a4 in the memset requires boosting the alignment of %a4.
define void @bar() {
Update Transforms tests to use CHECK-LABEL for easier debugging. No functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
2013-07-14 09:42:54 +08:00
; CHECK-LABEL: @bar(
The memcpy optimizer was happily doing call slot forwarding when the new memory was less aligned than the old. In the testcase this results in an overaligned memset: the memset alignment was correct for the original memory but is too much for the new memory. Fix this by either increasing the alignment of the new memory or bailing out if that isn't possible. Should fix the gcc-4.7 self-host buildbot failure. llvm-svn: 165220
2012-10-04 18:54:40 +08:00
; CHECK: %a4 = alloca i32, align 8
; CHECK-NOT: memcpy
%a4 = alloca i32, align 4
%a8 = alloca i32, align 8
%a8.cast = bitcast i32* %a8 to i8*
%a4.cast = bitcast i32* %a4 to i8*
call void @llvm.memset.p0i8.i64(i8* %a8.cast, i8 0, i64 4, i32 8, i1 false)
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %a4.cast, i8* %a8.cast, i64 4, i32 4, i1 false)
ret void
}