maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Analysis/LoopAccessAnalysis/store-to-invariant-check3.ll

55 lines
2.2 KiB
LLVM
Raw Normal View History

[LoopAccesses] Allow analysis to complete in the presence of uniform stores (Re-apply r234361 with a fix and a testcase for PR23157) Both run-time pointer checking and the dependence analysis are capable of dealing with uniform addresses. I.e. it's really just an orthogonal property of the loop that the analysis computes. Run-time pointer checking will only try to reason about SCEVAddRec pointers or else gives up. If the uniform pointer turns out the be a SCEVAddRec in an outer loop, the run-time checks generated will be correct (start and end bounds would be equal). In case of the dependence analysis, we work again with SCEVs. When compared against a loop-dependent address of the same underlying object, the difference of the two SCEVs won't be constant. This will result in returning an Unknown dependence for the pair. When compared against another uniform access, the difference would be constant and we should return the right type of dependence (forward/backward/etc). The changes also adds support to query this property of the loop and modify the vectorizer to use this. Patch by Ashutosh Nema! llvm-svn: 234424
2015-04-09 01:48:40 +08:00
; RUN: opt < %s -loop-accesses -analyze | FileCheck %s
[PM] Avoid getResult on a higher level in LoopAccessAnalysis Note that require<domtree> and require<loops> aren't needed because they come in implicitly via the loop pass manager. llvm-svn: 274712
2016-07-07 09:01:53 +08:00
; RUN: opt -passes='require<scalar-evolution>,require<aa>,loop(print-access-info)' -disable-output < %s 2>&1 | FileCheck %s
[LoopAccesses] Allow analysis to complete in the presence of uniform stores (Re-apply r234361 with a fix and a testcase for PR23157) Both run-time pointer checking and the dependence analysis are capable of dealing with uniform addresses. I.e. it's really just an orthogonal property of the loop that the analysis computes. Run-time pointer checking will only try to reason about SCEVAddRec pointers or else gives up. If the uniform pointer turns out the be a SCEVAddRec in an outer loop, the run-time checks generated will be correct (start and end bounds would be equal). In case of the dependence analysis, we work again with SCEVs. When compared against a loop-dependent address of the same underlying object, the difference of the two SCEVs won't be constant. This will result in returning an Unknown dependence for the pair. When compared against another uniform access, the difference would be constant and we should return the right type of dependence (forward/backward/etc). The changes also adds support to query this property of the loop and modify the vectorizer to use this. Patch by Ashutosh Nema! llvm-svn: 234424
2015-04-09 01:48:40 +08:00
; Test to confirm LAA will find store to invariant address.
; Inner loop has a store to invariant address.
;
; for(; i < itr; i++) {
; for(; j < itr; j++) {
; var1[j] = ++var2[i] + var1[j];
; }
; }
; CHECK: Store to invariant address was found in loop.
define void @foo(i32* nocapture %var1, i32* nocapture %var2, i32 %itr) #0 {
entry:
%cmp20 = icmp sgt i32 %itr, 0
br i1 %cmp20, label %for.cond1.preheader, label %for.end11
for.cond1.preheader: ; preds = %entry, %for.inc9
%indvars.iv23 = phi i64 [ %indvars.iv.next24, %for.inc9 ], [ 0, %entry ]
%j.022 = phi i32 [ %j.1.lcssa, %for.inc9 ], [ 0, %entry ]
%cmp218 = icmp slt i32 %j.022, %itr
br i1 %cmp218, label %for.body3.lr.ph, label %for.inc9
for.body3.lr.ph: ; preds = %for.cond1.preheader
%arrayidx = getelementptr inbounds i32, i32* %var2, i64 %indvars.iv23
%0 = sext i32 %j.022 to i64
br label %for.body3
for.body3: ; preds = %for.body3, %for.body3.lr.ph
%indvars.iv = phi i64 [ %0, %for.body3.lr.ph ], [ %indvars.iv.next, %for.body3 ]
%1 = load i32, i32* %arrayidx, align 4
%inc = add nsw i32 %1, 1
store i32 %inc, i32* %arrayidx, align 4
%arrayidx5 = getelementptr inbounds i32, i32* %var1, i64 %indvars.iv
%2 = load i32, i32* %arrayidx5, align 4
%add = add nsw i32 %inc, %2
store i32 %add, i32* %arrayidx5, align 4
%indvars.iv.next = add nsw i64 %indvars.iv, 1
%lftr.wideiv = trunc i64 %indvars.iv.next to i32
%exitcond = icmp eq i32 %lftr.wideiv, %itr
br i1 %exitcond, label %for.inc9, label %for.body3
for.inc9: ; preds = %for.body3, %for.cond1.preheader
%j.1.lcssa = phi i32 [ %j.022, %for.cond1.preheader ], [ %itr, %for.body3 ]
%indvars.iv.next24 = add nuw nsw i64 %indvars.iv23, 1
%lftr.wideiv25 = trunc i64 %indvars.iv.next24 to i32
%exitcond26 = icmp eq i32 %lftr.wideiv25, %itr
br i1 %exitcond26, label %for.end11, label %for.cond1.preheader
for.end11: ; preds = %for.inc9, %entry
ret void
}