maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/ScopDetect/index_from_unpredictable_lo...

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

93 lines
3.4 KiB
LLVM
Raw Normal View History

[SCEVValidator] Loop exit values of loops before the SCoP are synthesizable. In the following loop: int i; for (i = 0; i < func(); i+=1) ; SCoP: for (int j = 0; j<n; j+=1) S(i, j) The value i is synthesizable in the SCoP that includes only the j-loop. This is because i is fixed within the SCoP, it is irrelevant whether it originates from another loop. This fixes a strange case where a PHI was synthesiable in a SCoP, but not its incoming value, triggering an assertion. This should fix MultiSource/Applications/sgefa/sgefa of the perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable buildbot. llvm-svn: 309109
2017-07-26 21:05:45 +08:00
; RUN: opt %loadPolly -polly-scops -analyze < %s | FileCheck %s --check-prefix=AFFINE
; RUN: opt %loadPolly -polly-scops -polly-allow-nonaffine -analyze < %s | FileCheck %s --check-prefix=NONAFFINE
[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: *
[SCEVValidator] Loop exit values of loops before the SCoP are synthesizable. In the following loop: int i; for (i = 0; i < func(); i+=1) ; SCoP: for (int j = 0; j<n; j+=1) S(i, j) The value i is synthesizable in the SCoP that includes only the j-loop. This is because i is fixed within the SCoP, it is irrelevant whether it originates from another loop. This fixes a strange case where a PHI was synthesiable in a SCoP, but not its incoming value, triggering an assertion. This should fix MultiSource/Applications/sgefa/sgefa of the perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable buildbot. llvm-svn: 309109
2017-07-26 21:05:45 +08:00
; The loop for.body => for.inc has an unpredictable iteration count could due to
; the undef start value that it is compared to. Therefore the array element
; %arrayidx101 that depends on that exit value cannot be affine.
; Derived from test-suite/MultiSource/Benchmarks/BitBench/uuencode/uuencode.c
define void @encode_line(i8* nocapture readonly %input, i32 %octets, i64 %p, i32 %n) {
entry:
br label %outer.for
outer.for:
%j = phi i32 [0, %entry], [%j.inc, %for.end]
%j.cmp = icmp slt i32 %j, %n
br i1 %j.cmp, label %for.body, label %exit
for.body:
%indvars.iv = phi i64 [ %indvars.iv.next, %for.inc ], [ %p, %outer.for ]
%octets.addr.02 = phi i32 [ undef, %for.inc ], [ %octets, %outer.for ]
br i1 false, label %for.inc, label %if.else
if.else:
%cond = icmp eq i32 %octets.addr.02, 2
br i1 %cond, label %if.then84, label %for.end
if.then84:
%0 = add nsw i64 %indvars.iv, 1
%arrayidx101 = getelementptr inbounds i8, i8* %input, i64 %0
store i8 42, i8* %arrayidx101, align 1
br label %for.end
for.inc:
%cmp = icmp sgt i32 %octets.addr.02, 3
%indvars.iv.next = add nsw i64 %indvars.iv, 3
br i1 %cmp, label %for.body, label %for.end
for.end:
%j.inc = add nuw nsw i32 %j, 1
br label %outer.for
exit:
br label %return
return:
ret void
}
; AFFINE: Region: %if.else---%for.end
; AFFINE: Statements {
; AFFINE-NEXT: Stmt_if_then84
; AFFINE-NEXT: Domain :=
; AFFINE-NEXT: [octets, p_1, p] -> { Stmt_if_then84[] : octets = 2 };
; AFFINE-NEXT: Schedule :=
; AFFINE-NEXT: [octets, p_1, p] -> { Stmt_if_then84[] -> [] };
; AFFINE-NEXT: MustWriteAccess := [Reduction Type: NONE] [Scalar: 0]
; AFFINE-NEXT: [octets, p_1, p] -> { Stmt_if_then84[] -> MemRef_input[1 + p] };
; AFFINE-NEXT: }
; NONAFFINE: Region: %outer.for---%return
; NONAFFINE: Statements {
; NONAFFINE-NEXT: Stmt_for_body
; NONAFFINE-NEXT: Domain :=
; NONAFFINE-NEXT: [n, octets] -> { Stmt_for_body[i0, 0] : 0 <= i0 < n };
; NONAFFINE-NEXT: Schedule :=
; NONAFFINE-NEXT: [n, octets] -> { Stmt_for_body[i0, i1] -> [i0, 0, 0] };
; NONAFFINE-NEXT: MustWriteAccess := [Reduction Type: NONE] [Scalar: 1]
; NONAFFINE-NEXT: [n, octets] -> { Stmt_for_body[i0, i1] -> MemRef_indvars_iv[] };
; NONAFFINE-NEXT: Stmt_if_then84
; NONAFFINE-NEXT: Domain :=
; NONAFFINE-NEXT: [n, octets] -> { Stmt_if_then84[i0] : octets = 2 and 0 <= i0 < n };
; NONAFFINE-NEXT: Schedule :=
; NONAFFINE-NEXT: [n, octets] -> { Stmt_if_then84[i0] -> [i0, 1, 0] };
; NONAFFINE-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
; NONAFFINE-NEXT: [n, octets] -> { Stmt_if_then84[i0] -> MemRef_indvars_iv[] };
; NONAFFINE-NEXT: MayWriteAccess := [Reduction Type: NONE] [Scalar: 0]
; NONAFFINE-NEXT: [n, octets] -> { Stmt_if_then84[i0] -> MemRef_input[o0] };
; NONAFFINE-NEXT: }