summaryrefslogtreecommitdiffstats
path: root/llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll
diff options
context:
space:
mode:
authorAdam Nemet <anemet@apple.com>2015-06-26 17:25:43 +0000
committerAdam Nemet <anemet@apple.com>2015-06-26 17:25:43 +0000
commitc4866d29dd74336d4a7d09fd7b2ee730214d4dad (patch)
tree8391bede2bea24b113f40087efaca7efcd2b15d5 /llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll
parentec6b26b955a7a5c2d41bf65396a14a5531ac3638 (diff)
downloadbcm5719-llvm-c4866d29dd74336d4a7d09fd7b2ee730214d4dad.tar.gz
bcm5719-llvm-c4866d29dd74336d4a7d09fd7b2ee730214d4dad.zip
[LAA] Try to prove non-wrapping of pointers if SCEV cannot
Summary: Scalar evolution does not propagate the non-wrapping flags to values that are derived from a non-wrapping induction variable because the non-wrapping property could be flow-sensitive. This change is a first attempt to establish the non-wrapping property in some simple cases. The main idea is to look through the operations defining the pointer. As long as we arrive to a non-wrapping AddRec via a small chain of non-wrapping instruction, the pointer should not wrap either. I believe that this essentially is what Andy described in http://article.gmane.org/gmane.comp.compilers.llvm.cvs/220731 as the way forward. Reviewers: aschwaighofer, nadav, sanjoy, atrick Reviewed By: atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10472 llvm-svn: 240798
Diffstat (limited to 'llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll')
-rw-r--r--llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll41
1 files changed, 41 insertions, 0 deletions
diff --git a/llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll b/llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll
new file mode 100644
index 00000000000..0de1cd1bea6
--- /dev/null
+++ b/llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll
@@ -0,0 +1,41 @@
+; RUN: opt -basicaa -loop-accesses -analyze < %s | FileCheck %s
+
+; For this loop:
+; for (int i = 0; i < n; i++)
+; A[2 * i] = A[2 * i] + B[i];
+;
+; , SCEV is unable to prove that A[2 * i] does not overflow. However,
+; analyzing the IR helps us to conclude it and in turn allow dependence
+; analysis.
+
+target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
+
+; CHECK: Memory dependences are safe{{$}}
+
+define void @f(i16* noalias %a,
+ i16* noalias %b, i64 %N) {
+entry:
+ br label %for.body
+
+for.body: ; preds = %for.body, %entry
+ %ind = phi i64 [ 0, %entry ], [ %inc, %for.body ]
+
+ %mul = mul nuw nsw i64 %ind, 2
+
+ %arrayidxA = getelementptr inbounds i16, i16* %a, i64 %mul
+ %loadA = load i16, i16* %arrayidxA, align 2
+
+ %arrayidxB = getelementptr inbounds i16, i16* %b, i64 %ind
+ %loadB = load i16, i16* %arrayidxB, align 2
+
+ %add = mul i16 %loadA, %loadB
+
+ store i16 %add, i16* %arrayidxA, align 2
+
+ %inc = add nuw nsw i64 %ind, 1
+ %exitcond = icmp eq i64 %inc, %N
+ br i1 %exitcond, label %for.end, label %for.body
+
+for.end: ; preds = %for.body
+ ret void
+}
OpenPOWER on IntegriCloud