mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-12-14 11:32:34 +00:00
dd469afe15
Summary: This implements the initial version as was proposed earlier this year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/080462.html). Since then Loop Access Analysis was split out from the Loop Vectorizer and was made into a separate analysis pass. Loop Distribution becomes the second user of this analysis. The pass is off by default and can be enabled with -enable-loop-distribution. There is currently no notion of profitability; if there is a loop with dependence cycles, the pass will try to split them off from other memory operations into a separate loop. I decided to remove the control-dependence calculation from this first version. This and the issues with the PDT are actively discussed so it probably makes sense to treat it separately. Right now I just mark all terminator instruction required which keeps identical CFGs for each distributed loop. This seems to be working pretty well for 456.hmmer where even though there is an empty if-then block in the distributed loop initially, it gets completely removed. The pass keeps DominatorTree and LoopInfo updated. I've tested this with -loop-distribute-verify with the testsuite where we distribute ~90 loops. SimplifyLoop is violated in some cases and I have a FIXME covering this. Reviewers: hfinkel, nadav, aschwaighofer Reviewed By: aschwaighofer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8831 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237358 91177308-0d34-0410-b5e6-96231b3b80d8
66 lines
2.0 KiB
LLVM
66 lines
2.0 KiB
LLVM
; RUN: opt -loop-distribute -S -verify-loop-info -verify-dom-info < %s \
|
|
; RUN: | FileCheck %s
|
|
|
|
; Distributing this loop to avoid the dependence cycle would require to
|
|
; reorder S1 and S2 to form the two partitions: {S2} | {S1, S3}. The analysis
|
|
; provided by LoopAccessAnalysis does not allow us to reorder memory
|
|
; operations so make sure we bail on this loop.
|
|
;
|
|
; for (i = 0; i < n; i++) {
|
|
; S1: d = D[i];
|
|
; S2: A[i + 1] = A[i] * B[i];
|
|
; S3: C[i] = d * E[i];
|
|
; }
|
|
|
|
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
|
|
target triple = "x86_64-apple-macosx10.10.0"
|
|
|
|
define void @f(i32* noalias %a,
|
|
i32* noalias %b,
|
|
i32* noalias %c,
|
|
i32* noalias %d,
|
|
i32* noalias %e) {
|
|
entry:
|
|
br label %for.body
|
|
|
|
; CHECK: entry:
|
|
; CHECK: br label %for.body
|
|
; CHECK: for.body:
|
|
; CHECK: br i1 %exitcond, label %for.end, label %for.body
|
|
; CHECK: for.end:
|
|
; CHECK: ret void
|
|
|
|
for.body: ; preds = %for.body, %entry
|
|
%ind = phi i64 [ 0, %entry ], [ %add, %for.body ]
|
|
|
|
%arrayidxA = getelementptr inbounds i32, i32* %a, i64 %ind
|
|
%loadA = load i32, i32* %arrayidxA, align 4
|
|
|
|
%arrayidxB = getelementptr inbounds i32, i32* %b, i64 %ind
|
|
%loadB = load i32, i32* %arrayidxB, align 4
|
|
|
|
%mulA = mul i32 %loadB, %loadA
|
|
|
|
%arrayidxD = getelementptr inbounds i32, i32* %d, i64 %ind
|
|
%loadD = load i32, i32* %arrayidxD, align 4
|
|
|
|
%add = add nuw nsw i64 %ind, 1
|
|
%arrayidxA_plus_4 = getelementptr inbounds i32, i32* %a, i64 %add
|
|
store i32 %mulA, i32* %arrayidxA_plus_4, align 4
|
|
|
|
%arrayidxC = getelementptr inbounds i32, i32* %c, i64 %ind
|
|
|
|
%arrayidxE = getelementptr inbounds i32, i32* %e, i64 %ind
|
|
%loadE = load i32, i32* %arrayidxE, align 4
|
|
|
|
%mulC = mul i32 %loadD, %loadE
|
|
|
|
store i32 %mulC, i32* %arrayidxC, align 4
|
|
|
|
%exitcond = icmp eq i64 %add, 20
|
|
br i1 %exitcond, label %for.end, label %for.body
|
|
|
|
for.end: ; preds = %for.body
|
|
ret void
|
|
}
|