maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/ScopInfo/schedule-const-post-dominat...

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

49 lines
1.2 KiB
LLVM
Raw Normal View History

ScopInfo: Correct schedule construction For schedule generation we assumed that the reverse post order traversal used by the domain generation is sufficient, however it is not. Once a loop is discovered, we have to completely traverse it, before we can generate the schedule for any block/region that is only reachable through a loop exiting block. To this end, we add a "loop stack" that will keep track of loops we discovered during the traversal but have not yet traversed completely. We will never visit a basic block (or region) outside the most recent (thus smallest) loop in the loop stack but instead queue such blocks (or regions) in a waiting list. If the waiting list is not empty and (might) contain blocks from the most recent loop in the loop stack the next block/region to visit is drawn from there, otherwise from the reverse post order iterator. We exploit the new property of loops being always completed before additional loops are processed, by removing the LoopSchedules map and instead keep all information in LoopStack. This clarifies that we indeed always only keep a stack of in-process loops, but will never keep incomplete schedules for an arbitrary set of loops. As a result, we can simplify some of the existing code. This patch also adds some more documentation about how our schedule construction works. This fixes http://llvm.org/PR25879 This patch is an modified version of Johannes Doerfert's initial fix. Differential Revision: http://reviews.llvm.org/D15679 llvm-svn: 259354
2016-02-01 19:54:13 +08:00
; RUN: opt %loadPolly -analyze -polly-scops < %s | FileCheck %s
[ScopDetect] Reject loop with multiple exit blocks. The current statement domain derivation algorithm does not (always) consider that different exit blocks of a loop can have different conditions to be reached. From the code for (int i = n; ; i-=2) { if (i <= 0) goto even; if (i <= 1) goto odd; A[i] = i; } even: A[0] = 42; return; odd: A[1] = 21; return; Polly currently derives the following domains: Stmt_even_critedge Domain := [n] -> { Stmt_even_critedge[] }; Stmt_odd Domain := [n] -> { Stmt_odd[] : (1 + n) mod 2 = 0 and n > 0 }; while the domain for the odd case is correct, Stmt_even is assumed to be executed unconditionally, which is obviously wrong. While projecting out the loop dimension in `adjustDomainDimensions`, it does not consider that there are other exit condition that have matched before. I don't know a how to fix this without changing a lot of code. Therefore This patch rejects loops with multiple exist blocks to fix the miscompile of test-suite's uuencode. The odd condition is transformed by LLVM to %cmp1 = icmp eq i64 %indvars.iv, 1 such that the project_out in adjustDomainDimensions() indeed only matches for odd n (using this condition only, we'd have an infinite loop otherwise). The even condition manifests as %cmp = icmp slt i64 %indvars.iv, 3 Because buildDomainsWithBranchConstraints() does not consider other exit conditions, it has to assume that the induction variable will eventually be lower than 3 and taking this exit. IMHO we need to reuse the algorithm that determines the number of iterations (addLoopBoundsToHeaderDomain) to determine which exit condition applies first. It has to happen in buildDomainsWithBranchConstraints() because the result will need to propagate to successor BBs. Currently addLoopBoundsToHeaderDomain() just look for union of all backedge conditions (which means leaving not the loop here). The patch in llvm.org/PR35465 changes it to look for exit conditions instead. This is required because there might be other exit conditions that do not alternatively go back to the loop header. Differential Revision: https://reviews.llvm.org/D45649 llvm-svn: 330858
2018-04-26 02:53:33 +08:00
; The SCoP contains a loop with multiple exit blocks (BBs after leaving
; the loop). The current implementation of deriving their domain derives
; only a common domain for all of the exit blocks. We disabled loops with
; multiple exit blocks until this is fixed.
; XFAIL: *
ScopInfo: Correct schedule construction For schedule generation we assumed that the reverse post order traversal used by the domain generation is sufficient, however it is not. Once a loop is discovered, we have to completely traverse it, before we can generate the schedule for any block/region that is only reachable through a loop exiting block. To this end, we add a "loop stack" that will keep track of loops we discovered during the traversal but have not yet traversed completely. We will never visit a basic block (or region) outside the most recent (thus smallest) loop in the loop stack but instead queue such blocks (or regions) in a waiting list. If the waiting list is not empty and (might) contain blocks from the most recent loop in the loop stack the next block/region to visit is drawn from there, otherwise from the reverse post order iterator. We exploit the new property of loops being always completed before additional loops are processed, by removing the LoopSchedules map and instead keep all information in LoopStack. This clarifies that we indeed always only keep a stack of in-process loops, but will never keep incomplete schedules for an arbitrary set of loops. As a result, we can simplify some of the existing code. This patch also adds some more documentation about how our schedule construction works. This fixes http://llvm.org/PR25879 This patch is an modified version of Johannes Doerfert's initial fix. Differential Revision: http://reviews.llvm.org/D15679 llvm-svn: 259354
2016-02-01 19:54:13 +08:00
; CHECK: Stmt_loopA[i0] -> [0, 0, 0]
; CHECK-DAG: Stmt_loopB[i0] -> [0, 0, 1]
; CHECK-DAG: Stmt_bbB[] -> [1, 0, 0]
; CHECK-DAG: Stmt_bbA[] -> [2, 0, 0]
; CHECK-DAG: Stmt_bbMerge[] -> [3, 0, 0]
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
define void @hoge(i64 %p0, i64 %p1, i64 %p2, i64 %p3, float* %A) {
entry:
br label %loopA
loopA:
%tmp4 = phi i64 [ 0, %entry ], [ 0, %loopB]
store float 42.0, float* %A
%cmp0 = icmp sle i64 %p0, 100
br i1 %cmp0, label %loopB, label %bbB
loopB:
store float 42.0, float* %A
%cmp1 = icmp sle i64 %p1, 100
br i1 %cmp1, label %loopA, label %bbA
bbA:
store float 42.0, float* %A
%cmpbbA = icmp sle i64 %p2, 50
br i1 %cmpbbA, label %bbMerge, label %exit
bbB:
store float 42.0, float* %A
%cmpbbB= icmp sle i64 %p3, 200
br i1 %cmpbbB, label %exit, label %bbMerge
bbMerge:
store float 42.0, float* %A
br label %exit
exit:
ret void
}