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/NonAffine/non_affine_loop_used_later.ll

139 lines
5.7 KiB
LLVM
Raw Normal View History

tests: Explicitly state if profitability tests should be used Polly's profitability heuristic saves compile time by skipping trivial scops or scops were we know no good optimization can be applied. For almost all our tests this heuristic makes little sense as we aim for minimal test cases when testing functionality. Hence, in almost all cases this heuristic is better be disabled. In preparation of disabling Polly's compile time heuristic by default in the test suite we first explicitly enable it in the couple of test cases that really use it (or run with/without heuristic side-by-side). llvm-svn: 249418
2015-10-06 23:19:35 +08:00
; RUN: opt %loadPolly -polly-detect-unprofitable -polly-scops \
; RUN: -polly-allow-nonaffine -polly-allow-nonaffine-branches \
; RUN: -polly-allow-nonaffine-loops -analyze < %s | FileCheck %s
; RUN: opt %loadPolly -polly-scops -polly-allow-nonaffine \
; RUN: -polly-detect-unprofitable=false \
; RUN: -polly-allow-nonaffine-branches -polly-allow-nonaffine-loops \
; RUN: -analyze < %s | FileCheck %s --check-prefix=PROFIT
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
;
; Verify that we over approximate the read acces of A[j] in the last statement as j is
; computed in a non-affine loop we do not model.
;
; CHECK: Function: f
; CHECK: Region: %bb2---%bb24
; CHECK: Max Loop Depth: 1
; CHECK: Context:
Use modulo semantic to generate non-integer-overflow assumptions This will allow to generate non-wrap assumptions for integer expressions that are part of the SCoP. We compare the common isl representation of the expression with one computed with modulo semantic. For all parameter combinations they are not equal we can have integer overflows. The nsw flags are respected when the modulo representation is computed, nuw and nw flags are ignored for now. In order to not increase compile time to much, the non-wrap assumptions are collected in a separate boundary context instead of the assumed context. This helps compile time as the boundary context can become complex and it is therefor not advised to use it in other operations except runtime check generation. However, the assumed context is e.g., used to tighten dependences. While the boundary context might help to tighten the assumed context it is doubtful that it will help in practice (it does not effect lnt much) as the boundary (or no-wrap assumptions) only restrict the very end of the possible value range of parameters. PET uses a different approach to compute the no-wrap context, though lnt runs have shown that this version performs slightly better for us. llvm-svn: 247732
2015-09-16 06:52:53 +08:00
; CHECK: [N] -> { :
; CHECK-DAG: N >= -2147483648
; CHECK-DAG: and
; CHECK-DAG: N <= 2147483647
; CHECK: }
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: Assumed Context:
; CHECK: [N] -> { : }
; CHECK: p0: %N
; CHECK: Alias Groups (0):
; CHECK: n/a
; CHECK: Statements {
; CHECK: Stmt_bb2
Keep track of ScopArrayInfo objects that model PHI node storage Summary: When translating PHI nodes into memory dependences during code generation we require two kinds of memory. 'Normal memory' as for all scalar dependences and 'PHI node memory' to store the incoming values of the PHI node. With this patch we now mark and track these two kinds of memories, which we previously incorrectly marked as a single memory object. Being aware of PHI node storage makes code generation easier, as we do not need to guess what kind of storage a scalar reference requires. This simplifies the code nicely. Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D11554 llvm-svn: 243420
2015-07-28 22:53:44 +08:00
; CHECK: [N] -> { Stmt_bb2[i0] -> MemRef_j_0__phi[] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: MustWriteAccess := [Reduction Type: NONE] [Scalar: 1]
; CHECK: [N] -> { Stmt_bb2[i0] -> MemRef_j_0[] };
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: Stmt_bb4__TO__bb18
Rename 'scattering' to 'schedule' In Polly we used both the term 'scattering' and the term 'schedule' to describe the execution order of a statement without actually distinguishing between them. We now uniformly use the term 'schedule' for the execution order. This corresponds to the terminology of isl. History: CLooG introduced the term scattering as the generated code can be used as a sequential execution order (schedule) or as a parallel dimension enumerating different threads of execution (placement). In Polly and/or isl the term placement was never used, but we uniformly refer to an execution order as a schedule and only later introduce parallelism. When doing so we do not talk about about specific placement dimensions. llvm-svn: 235380
2015-04-21 19:37:25 +08:00
; CHECK: Schedule :=
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> [i0, 1] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_A[i0] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_A[i0] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: MayWriteAccess := [Reduction Type: NONE] [Scalar: 0]
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_A[i0] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
Make non-affine statement names isl compatible Named isl sets can generally have any name if they remain within Polly, but only certain strings can be parsed by isl. The new names we create ensure that we can always copy-past isl strings from Polly to other isl tools, e.g. for debugging. llvm-svn: 241787
2015-07-09 15:31:45 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_smax[] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: MayWriteAccess := [Reduction Type: NONE] [Scalar: 1]
Keep track of ScopArrayInfo objects that model PHI node storage Summary: When translating PHI nodes into memory dependences during code generation we require two kinds of memory. 'Normal memory' as for all scalar dependences and 'PHI node memory' to store the incoming values of the PHI node. With this patch we now mark and track these two kinds of memories, which we previously incorrectly marked as a single memory object. Being aware of PHI node storage makes code generation easier, as we do not need to guess what kind of storage a scalar reference requires. This simplifies the code nicely. Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D11554 llvm-svn: 243420
2015-07-28 22:53:44 +08:00
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_j_2__phi[] };
Earlier creation of ScopStmt objects This moves the construction of ScopStmt to the beginning of the ScopInfo pass. The late creation was a result of the earlier separation of ScopInfo and TempScopInfo. This will avoid introducing more ScopStmt-like maps in future commits. The AccFuncMap will also be removed in some future commit. DomainMap might also be included into ScopStmt. The order in which ScopStmt are created changes and initially creates empty statements that are removed in a simplification. Differential Revision: http://reviews.llvm.org/D13341 llvm-svn: 249132
2015-10-02 21:53:07 +08:00
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_j_0[] };
; CHECK: MustWriteAccess := [Reduction Type: NONE] [Scalar: 1]
; CHECK: [N] -> { Stmt_bb4__TO__bb18[i0] -> MemRef_j_2__phi[] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: Stmt_bb18
Rename 'scattering' to 'schedule' In Polly we used both the term 'scattering' and the term 'schedule' to describe the execution order of a statement without actually distinguishing between them. We now uniformly use the term 'schedule' for the execution order. This corresponds to the terminology of isl. History: CLooG introduced the term scattering as the generated code can be used as a sequential execution order (schedule) or as a parallel dimension enumerating different threads of execution (placement). In Polly and/or isl the term placement was never used, but we uniformly refer to an execution order as a schedule and only later introduce parallelism. When doing so we do not talk about about specific placement dimensions. llvm-svn: 235380
2015-04-21 19:37:25 +08:00
; CHECK: Schedule :=
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: [N] -> { Stmt_bb18[i0] -> [i0, 2] };
; CHECK: MustWriteAccess := [Reduction Type: NONE] [Scalar: 1]
; CHECK: [N] -> { Stmt_bb18[i0] -> MemRef_j_2[] };
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
Keep track of ScopArrayInfo objects that model PHI node storage Summary: When translating PHI nodes into memory dependences during code generation we require two kinds of memory. 'Normal memory' as for all scalar dependences and 'PHI node memory' to store the incoming values of the PHI node. With this patch we now mark and track these two kinds of memories, which we previously incorrectly marked as a single memory object. Being aware of PHI node storage makes code generation easier, as we do not need to guess what kind of storage a scalar reference requires. This simplifies the code nicely. Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D11554 llvm-svn: 243420
2015-07-28 22:53:44 +08:00
; CHECK: [N] -> { Stmt_bb18[i0] -> MemRef_j_2__phi[] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK: [N] -> { Stmt_bb18[i0] -> MemRef_A[o0] : o0 >= -2147483648 and o0 <= 2147483645 };
; CHECK: MustWriteAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK: [N] -> { Stmt_bb18[i0] -> MemRef_A[i0] };
; CHECK: Stmt_bb23
Rename 'scattering' to 'schedule' In Polly we used both the term 'scattering' and the term 'schedule' to describe the execution order of a statement without actually distinguishing between them. We now uniformly use the term 'schedule' for the execution order. This corresponds to the terminology of isl. History: CLooG introduced the term scattering as the generated code can be used as a sequential execution order (schedule) or as a parallel dimension enumerating different threads of execution (placement). In Polly and/or isl the term placement was never used, but we uniformly refer to an execution order as a schedule and only later introduce parallelism. When doing so we do not talk about about specific placement dimensions. llvm-svn: 235380
2015-04-21 19:37:25 +08:00
; CHECK: Schedule :=
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: [N] -> { Stmt_bb23[i0] -> [i0, 3] };
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
; CHECK: [N] -> { Stmt_bb23[i0] -> MemRef_j_2[] };
; CHECK: MustWriteAccess := [Reduction Type: NONE] [Scalar: 1]
Keep track of ScopArrayInfo objects that model PHI node storage Summary: When translating PHI nodes into memory dependences during code generation we require two kinds of memory. 'Normal memory' as for all scalar dependences and 'PHI node memory' to store the incoming values of the PHI node. With this patch we now mark and track these two kinds of memories, which we previously incorrectly marked as a single memory object. Being aware of PHI node storage makes code generation easier, as we do not need to guess what kind of storage a scalar reference requires. This simplifies the code nicely. Reviewers: jdoerfert Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D11554 llvm-svn: 243420
2015-07-28 22:53:44 +08:00
; CHECK: [N] -> { Stmt_bb23[i0] -> MemRef_j_0__phi[] };
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; CHECK: }
;
[FIX] Count affine loops correctly The "unprofitable" heuristic was broken and counted boxed loops even though we do not represent and optimize them. llvm-svn: 249274
2015-10-04 22:56:08 +08:00
; PROFIT-NOT: Statements
;
Allow loops in non-affine subregions -- SCoP Modeling This will allow the ScopInfo to build the polyhedral representation for non-affine regions that contain loops. Such loops are basically not visible in the SCoP representation. Accesses that are variant in such loops are therefor represented as non-affine accesses. Differential Revision: http://reviews.llvm.org/D8153 llvm-svn: 234713
2015-04-13 06:58:40 +08:00
; void f(int *A, int N, int M) {
; int i = 0, j = 0;
; for (i = 0; i < N; i++) {
; if (A[i])
; for (j = 0; j < M; j++)
; A[i]++;
; A[i] = A[j];
; }
; }
;
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
define void @f(i32* %A, i32 %N, i32 %M) {
bb:
%tmp = icmp sgt i32 %M, 0
%smax = select i1 %tmp, i32 %M, i32 0
%tmp1 = sext i32 %N to i64
br label %bb2
bb2: ; preds = %bb23, %bb
%indvars.iv = phi i64 [ %indvars.iv.next, %bb23 ], [ 0, %bb ]
%j.0 = phi i32 [ 0, %bb ], [ %j.2, %bb23 ]
%tmp3 = icmp slt i64 %indvars.iv, %tmp1
br i1 %tmp3, label %bb4, label %bb24
bb4: ; preds = %bb2
%tmp5 = getelementptr inbounds i32, i32* %A, i64 %indvars.iv
%tmp6 = load i32, i32* %tmp5, align 4
%tmp7 = icmp eq i32 %tmp6, 0
br i1 %tmp7, label %bb18, label %bb8
bb8: ; preds = %bb4
br label %bb9
bb9: ; preds = %bb15, %bb8
%j.1 = phi i32 [ 0, %bb8 ], [ %tmp16, %bb15 ]
%tmp10 = icmp slt i32 %j.1, %M
br i1 %tmp10, label %bb11, label %bb17
bb11: ; preds = %bb9
%tmp12 = getelementptr inbounds i32, i32* %A, i64 %indvars.iv
%tmp13 = load i32, i32* %tmp12, align 4
%tmp14 = add nsw i32 %tmp13, 1
store i32 %tmp14, i32* %tmp12, align 4
br label %bb15
bb15: ; preds = %bb11
%tmp16 = add nuw nsw i32 %j.1, 1
br label %bb9
bb17: ; preds = %bb9
br label %bb18
bb18: ; preds = %bb4, %bb17
%j.2 = phi i32 [ %smax, %bb17 ], [ %j.0, %bb4 ]
%tmp19 = sext i32 %j.2 to i64
%tmp20 = getelementptr inbounds i32, i32* %A, i64 %tmp19
%tmp21 = load i32, i32* %tmp20, align 4
%tmp22 = getelementptr inbounds i32, i32* %A, i64 %indvars.iv
store i32 %tmp21, i32* %tmp22, align 4
br label %bb23
bb23: ; preds = %bb18
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
br label %bb2
bb24: ; preds = %bb2
ret void
}