diff options
author | Adam Nemet <anemet@apple.com> | 2015-06-26 17:25:43 +0000 |
---|---|---|
committer | Adam Nemet <anemet@apple.com> | 2015-06-26 17:25:43 +0000 |
commit | c4866d29dd74336d4a7d09fd7b2ee730214d4dad (patch) | |
tree | 8391bede2bea24b113f40087efaca7efcd2b15d5 /llvm/test/Analysis/LoopAccessAnalysis/non-wrapping-pointer.ll | |
parent | ec6b26b955a7a5c2d41bf65396a14a5531ac3638 (diff) | |
download | bcm5719-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.ll | 41 |
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 +} |