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-condition-d...

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

95 lines
3.3 KiB
LLVM
Raw Normal View History

[BasicAA] Replace -basicaa with -basic-aa in polly Follow up to https://reviews.llvm.org/D82607.
2020-07-01 06:40:24 +08:00
; RUN: opt %loadPolly -basic-aa -polly-scops \
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: -polly-allow-nonaffine -polly-allow-nonaffine-branches \
; RUN: -polly-allow-nonaffine-loops=true -analyze < %s | FileCheck %s \
; RUN: -check-prefix=SCALAR
[BasicAA] Replace -basicaa with -basic-aa in polly Follow up to https://reviews.llvm.org/D82607.
2020-07-01 06:40:24 +08:00
; RUN: opt %loadPolly -basic-aa -polly-scops -polly-allow-nonaffine \
Introduce -polly-process-unprofitable This single option replaces -polly-detect-unprofitable and -polly-no-early-exit and is supposed to be the only option that disables compile-time heuristics that aim to bail out early on scops that are believed to not benefit from Polly optimizations. Suggested-by: Johannes Doerfert llvm-svn: 249426
2015-10-07 00:10:29 +08:00
; RUN: -polly-process-unprofitable=false \
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: -polly-allow-nonaffine-branches -polly-allow-nonaffine-loops=true \
; 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
;
Prepare unit tests for update to ISL 0.16 ISL 0.16 will change how sets are printed which breaks 117 unit tests that text-compare printed sets. This patch re-formats most of these unit tests using a script and small manual editing on top of that. When actually updating ISL, most work is done by just re-running the script to adapt to the changed output. Some tests that compare IR and tests with single CHECK-lines that can be easily updated manually are not included here. The re-format script will also be committed afterwards. The per-test formatter invocation command lines options will not be added in the near future because it is ad hoc and would overwrite the manual edits. Ideally it also shouldn't be required anymore because ISL's set printing has become more stable in 0.16. Differential Revision: http://reviews.llvm.org/D16095 llvm-svn: 257851
2016-01-15 08:48:42 +08:00
; SCALAR: Function: f
; SCALAR-NEXT: Region: %bb1---%bb13
; SCALAR-NEXT: Max Loop Depth: 1
; SCALAR-NEXT: Invariant Accesses: {
; SCALAR-NEXT: }
; SCALAR-NEXT: Context:
; SCALAR-NEXT: { : }
; SCALAR-NEXT: Assumed Context:
; SCALAR-NEXT: { : }
Track assumptions and restrictions separatly In order to speed up compile time and to avoid random timeouts we now separately track assumptions and restrictions. In this context assumptions describe parameter valuations we need and restrictions describe parameter valuations we do not allow. During AST generation we create a runtime check for both, whereas the one for the restrictions is negated before a conjunction is build. Except the In-Bounds assumptions we currently only track restrictions. Differential Revision: http://reviews.llvm.org/D17247 llvm-svn: 262328
2016-03-01 21:06:28 +08:00
; SCALAR-NEXT: Invalid Context:
Update isl to isl-0.18-1047-g4a20ef8 This update: - Removes several deprecated functions (e.g., isl_band). - Improves the pretty-printing of sets by detecting modulos and "false" equalities. - Minor improvements to coalescing and increased robustness of the isl scheduler. This update does not yet include isl commit isl-0.18-90-gd00cb45 (isl_pw_*_alloc: add missing check for compatible spaces, Wed Sep 6 12:18:04 2017 +0200), as this additional check is too tight and unfortunately causes two test case failures in Polly. A patch has been submitted to isl and will be included in the next isl update for Polly. llvm-svn: 325557
2018-02-20 15:26:42 +08:00
; SCALAR-NEXT: { : false }
Prepare unit tests for update to ISL 0.16 ISL 0.16 will change how sets are printed which breaks 117 unit tests that text-compare printed sets. This patch re-formats most of these unit tests using a script and small manual editing on top of that. When actually updating ISL, most work is done by just re-running the script to adapt to the changed output. Some tests that compare IR and tests with single CHECK-lines that can be easily updated manually are not included here. The re-format script will also be committed afterwards. The per-test formatter invocation command lines options will not be added in the near future because it is ad hoc and would overwrite the manual edits. Ideally it also shouldn't be required anymore because ISL's set printing has become more stable in 0.16. Differential Revision: http://reviews.llvm.org/D16095 llvm-svn: 257851
2016-01-15 08:48:42 +08:00
; SCALAR-NEXT: Arrays {
; SCALAR-NEXT: i32 MemRef_C[*]; // Element size 4
; SCALAR-NEXT: i32 MemRef_A[*]; // Element size 4
; SCALAR-NEXT: }
; SCALAR-NEXT: Arrays (Bounds as pw_affs) {
; SCALAR-NEXT: i32 MemRef_C[*]; // Element size 4
; SCALAR-NEXT: i32 MemRef_A[*]; // Element size 4
; SCALAR-NEXT: }
; SCALAR-NEXT: Alias Groups (0):
; SCALAR-NEXT: n/a
; SCALAR-NEXT: Statements {
; SCALAR-NEXT: Stmt_bb3__TO__bb11
; SCALAR-NEXT: Domain :=
Update to ISL 0.16.1 llvm-svn: 257898
2016-01-15 23:54:45 +08:00
; SCALAR-NEXT: { Stmt_bb3__TO__bb11[i0] : 0 <= i0 <= 1023 };
Prepare unit tests for update to ISL 0.16 ISL 0.16 will change how sets are printed which breaks 117 unit tests that text-compare printed sets. This patch re-formats most of these unit tests using a script and small manual editing on top of that. When actually updating ISL, most work is done by just re-running the script to adapt to the changed output. Some tests that compare IR and tests with single CHECK-lines that can be easily updated manually are not included here. The re-format script will also be committed afterwards. The per-test formatter invocation command lines options will not be added in the near future because it is ad hoc and would overwrite the manual edits. Ideally it also shouldn't be required anymore because ISL's set printing has become more stable in 0.16. Differential Revision: http://reviews.llvm.org/D16095 llvm-svn: 257851
2016-01-15 08:48:42 +08:00
; SCALAR-NEXT: Schedule :=
; SCALAR-NEXT: { Stmt_bb3__TO__bb11[i0] -> [i0] };
; SCALAR-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; SCALAR-NEXT: { Stmt_bb3__TO__bb11[i0] -> MemRef_C[i0] };
; SCALAR-NEXT: ReadAccess := [Reduction Type: +] [Scalar: 0]
Do not use wrapping ranges to bound non-affine accesses When deriving the range of valid values of a scalar evolution expression might be a range [12, 8), where the upper bound is smaller than the lower bound and where the range is expected to possibly wrap around. We theoretically could model such a range as a union of two non-wrapping ranges, but do not do this as of yet. Instead, we just do not derive any bounds. Before this change, we could have obtained bounds where the maximal possible value is strictly smaller than the minimal possible value, which is incorrect and also caused assertions during scop modeling. llvm-svn: 294891
2017-02-12 16:11:12 +08:00
; SCALAR-NEXT: { Stmt_bb3__TO__bb11[i0] -> MemRef_A[o0] };
Prepare unit tests for update to ISL 0.16 ISL 0.16 will change how sets are printed which breaks 117 unit tests that text-compare printed sets. This patch re-formats most of these unit tests using a script and small manual editing on top of that. When actually updating ISL, most work is done by just re-running the script to adapt to the changed output. Some tests that compare IR and tests with single CHECK-lines that can be easily updated manually are not included here. The re-format script will also be committed afterwards. The per-test formatter invocation command lines options will not be added in the near future because it is ad hoc and would overwrite the manual edits. Ideally it also shouldn't be required anymore because ISL's set printing has become more stable in 0.16. Differential Revision: http://reviews.llvm.org/D16095 llvm-svn: 257851
2016-01-15 08:48:42 +08:00
; SCALAR-NEXT: MayWriteAccess := [Reduction Type: +] [Scalar: 0]
Do not use wrapping ranges to bound non-affine accesses When deriving the range of valid values of a scalar evolution expression might be a range [12, 8), where the upper bound is smaller than the lower bound and where the range is expected to possibly wrap around. We theoretically could model such a range as a union of two non-wrapping ranges, but do not do this as of yet. Instead, we just do not derive any bounds. Before this change, we could have obtained bounds where the maximal possible value is strictly smaller than the minimal possible value, which is incorrect and also caused assertions during scop modeling. llvm-svn: 294891
2017-02-12 16:11:12 +08:00
; SCALAR-NEXT: { Stmt_bb3__TO__bb11[i0] -> MemRef_A[o0] };
Prepare unit tests for update to ISL 0.16 ISL 0.16 will change how sets are printed which breaks 117 unit tests that text-compare printed sets. This patch re-formats most of these unit tests using a script and small manual editing on top of that. When actually updating ISL, most work is done by just re-running the script to adapt to the changed output. Some tests that compare IR and tests with single CHECK-lines that can be easily updated manually are not included here. The re-format script will also be committed afterwards. The per-test formatter invocation command lines options will not be added in the near future because it is ad hoc and would overwrite the manual edits. Ideally it also shouldn't be required anymore because ISL's set printing has become more stable in 0.16. Differential Revision: http://reviews.llvm.org/D16095 llvm-svn: 257851
2016-01-15 08:48:42 +08:00
; SCALAR-NEXT: }
Make use of scalar/phi code generation explicit in the tests This ensures we pass all tests independently of how we set the options -disable-polly-intra-scop-scalar-to-array and -polly-model-phi-nodes. (At least if we enable both or disable both. Enabling them individually makes little sense, as they will hopefully disappear soon anyhow). llvm-svn: 238087
2015-05-23 11:34:35 +08:00
[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 * restrict A, int * restrict C) {
; int j;
; for (int i = 0; i < 1024; i++) {
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
; while ((j = C[i++])) {
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
; A[j]++;
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
; if (true) break;
; }
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
; }
; }
;
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
define void @f(i32* noalias %A, i32* noalias %C) {
bb:
br label %bb1
bb1: ; preds = %bb12, %bb
%indvars.iv = phi i64 [ %indvars.iv.next, %bb12 ], [ 0, %bb ]
%exitcond = icmp ne i64 %indvars.iv, 1024
br i1 %exitcond, label %bb2, label %bb13
bb2: ; preds = %bb1
br label %bb3
bb3: ; preds = %bb6, %bb2
%tmp = getelementptr inbounds i32, i32* %C, i64 %indvars.iv
%tmp4 = load i32, i32* %tmp, align 4
%tmp5 = icmp eq i32 %tmp4, 0
br i1 %tmp5, label %bb11, label %bb6
bb6: ; preds = %bb3
%tmp7 = sext i32 %tmp4 to i64
%tmp8 = getelementptr inbounds i32, i32* %A, i64 %tmp7
%tmp9 = load i32, i32* %tmp8, align 4
%tmp10 = add nsw i32 %tmp9, 1
store i32 %tmp10, i32* %tmp8, align 4
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
br i1 true, label %bb11, label %bb3
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
bb11: ; preds = %bb3
br label %bb12
bb12: ; preds = %bb11
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
br label %bb1
bb13: ; preds = %bb1
ret void
}