maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/ScopDetectionDiagnostics/ReportLoopBound-01.ll

116 lines
6.2 KiB
LLVM
Raw Normal View History

tests: Drop -polly-detect-unprofitable and -polly-no-early-exit These flags are now always passed to all tests and need to be disabled if not needed. Disabling these flags, rather than passing them to almost all tests, significantly simplfies our RUN: lines. llvm-svn: 249422
2015-10-06 23:36:44 +08:00
; RUN: opt %loadPolly \
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: -pass-remarks-missed="polly-detect" -polly-detect-track-failures \
; RUN: -polly-allow-nonaffine-loops=false -polly-detect -analyze \
; RUN: < %s 2>&1| FileCheck %s --check-prefix=REJECTNONAFFINELOOPS
tests: Drop -polly-detect-unprofitable and -polly-no-early-exit These flags are now always passed to all tests and need to be disabled if not needed. Disabling these flags, rather than passing them to almost all tests, significantly simplfies our RUN: lines. llvm-svn: 249422
2015-10-06 23:36:44 +08:00
; RUN: opt %loadPolly \
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: -pass-remarks-missed="polly-detect" -polly-detect-track-failures \
; RUN: -polly-allow-nonaffine-loops=true -polly-detect -analyze \
; RUN: < %s 2>&1| FileCheck %s --check-prefix=ALLOWNONAFFINELOOPS
; RUN: opt %loadPolly -pass-remarks-missed="polly-detect" \
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-detect-track-failures -polly-allow-nonaffine-loops=true \
; RUN: -polly-allow-nonaffine -polly-detect -analyze < %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=ALLOWNONAFFINEALL
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
; void f(int A[], int n) {
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
; for (int i = 0; i < A[n+i]; i++)
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
; A[i] = 0;
; }
Allow loops in non-affine subregions -- SCoP Detection This will allow the ScopDetection to detect non-affine regions that contain loops. All loops contained will be collected and are accessible to later passes in order to adjust the access functions. As the loops are non-affine and will not be part of the polyhedral representation later, all accesses that are variant in these loops have to be over approximated as non-affine accesses. They are therefore handled the same way as other non-affine accesses. Additionally, we do not count non-affine loops for the profitability heuristic, thus a region with only a non-affine loop will only be detected if the general detection of loop free regions is enabled. Differential Revision: http://reviews.llvm.org/D8152 llvm-svn: 234711
2015-04-13 06:52:20 +08:00
; If we reject non-affine loops the non-affine loop bound will be reported:
;
Cleanup rejection log handling [NFC] This patch cleans up the rejection log handling during the ScopDetection. It consists of two interconnected parts: - We keep all detection contexts for a function in order to provide more information to the user, e.g., about the rejection of extended/intermediate regions. - We remove the mutable "RejectLogs" member as the information is available through the detection contexts. llvm-svn: 269323
2016-05-13 02:50:01 +08:00
; REJECTNONAFFINELOOPS: remark: ReportLoopBound-01.c:1:12: The following errors keep this region from being a Scop.
Allow loops in non-affine subregions -- SCoP Detection This will allow the ScopDetection to detect non-affine regions that contain loops. All loops contained will be collected and are accessible to later passes in order to adjust the access functions. As the loops are non-affine and will not be part of the polyhedral representation later, all accesses that are variant in these loops have to be over approximated as non-affine accesses. They are therefore handled the same way as other non-affine accesses. Additionally, we do not count non-affine loops for the profitability heuristic, thus a region with only a non-affine loop will only be detected if the general detection of loop free regions is enabled. Differential Revision: http://reviews.llvm.org/D8152 llvm-svn: 234711
2015-04-13 06:52:20 +08:00
; REJECTNONAFFINELOOPS: remark: ReportLoopBound-01.c:2:8: Failed to derive an affine function from the loop bounds.
; REJECTNONAFFINELOOPS: remark: ReportLoopBound-01.c:3:5: Invalid Scop candidate ends here.
; If we allow non-affine loops the non-affine access will be reported:
;
Cleanup rejection log handling [NFC] This patch cleans up the rejection log handling during the ScopDetection. It consists of two interconnected parts: - We keep all detection contexts for a function in order to provide more information to the user, e.g., about the rejection of extended/intermediate regions. - We remove the mutable "RejectLogs" member as the information is available through the detection contexts. llvm-svn: 269323
2016-05-13 02:50:01 +08:00
; ALLOWNONAFFINELOOPS: remark: ReportLoopBound-01.c:1:12: The following errors keep this region from being a Scop.
Allow loops in non-affine subregions -- SCoP Detection This will allow the ScopDetection to detect non-affine regions that contain loops. All loops contained will be collected and are accessible to later passes in order to adjust the access functions. As the loops are non-affine and will not be part of the polyhedral representation later, all accesses that are variant in these loops have to be over approximated as non-affine accesses. They are therefore handled the same way as other non-affine accesses. Additionally, we do not count non-affine loops for the profitability heuristic, thus a region with only a non-affine loop will only be detected if the general detection of loop free regions is enabled. Differential Revision: http://reviews.llvm.org/D8152 llvm-svn: 234711
2015-04-13 06:52:20 +08:00
; ALLOWNONAFFINELOOPS: remark: ReportLoopBound-01.c:3:5: The array subscript of "A" is not affine
; ALLOWNONAFFINELOOPS: remark: ReportLoopBound-01.c:3:5: Invalid Scop candidate ends here.
; If we allow non-affine loops and non-affine accesses the region will be reported as not profitable:
;
Cleanup rejection log handling [NFC] This patch cleans up the rejection log handling during the ScopDetection. It consists of two interconnected parts: - We keep all detection contexts for a function in order to provide more information to the user, e.g., about the rejection of extended/intermediate regions. - We remove the mutable "RejectLogs" member as the information is available through the detection contexts. llvm-svn: 269323
2016-05-13 02:50:01 +08:00
; ALLOWNONAFFINEALL: remark: ReportLoopBound-01.c:1:12: The following errors keep this region from being a Scop.
; ALLOWNONAFFINEALL: remark: ReportLoopBound-01.c:1:12: No profitable polyhedral optimization found
Allow loops in non-affine subregions -- SCoP Detection This will allow the ScopDetection to detect non-affine regions that contain loops. All loops contained will be collected and are accessible to later passes in order to adjust the access functions. As the loops are non-affine and will not be part of the polyhedral representation later, all accesses that are variant in these loops have to be over approximated as non-affine accesses. They are therefore handled the same way as other non-affine accesses. Additionally, we do not count non-affine loops for the profitability heuristic, thus a region with only a non-affine loop will only be detected if the general detection of loop free regions is enabled. Differential Revision: http://reviews.llvm.org/D8152 llvm-svn: 234711
2015-04-13 06:52:20 +08:00
; ALLOWNONAFFINEALL: remark: ReportLoopBound-01.c:3:5: Invalid Scop candidate ends here.
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
Adjust debug metadata to LLVM changes in 252219 llvm-svn: 252273
2015-11-06 14:27:39 +08:00
define void @f(i32* %A, i32 %n) !dbg !4 {
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
entry:
br label %entry.split
entry.split: ; preds = %entry
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
tail call void @llvm.dbg.value(metadata i32* %A, i64 0, metadata !13, metadata !DIExpression()), !dbg !14
tail call void @llvm.dbg.value(metadata i32* %A, i64 0, metadata !13, metadata !DIExpression()), !dbg !14
tail call void @llvm.dbg.value(metadata i32 %n, i64 0, metadata !15, metadata !DIExpression()), !dbg !16
tail call void @llvm.dbg.value(metadata i32 0, i64 0, metadata !18, metadata !DIExpression()), !dbg !20
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
%idxprom = sext i32 %n to i64, !dbg !21
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%arrayidx = getelementptr inbounds i32, i32* %A, i64 %idxprom, !dbg !21
Update Polly tests to handle explicitly typed load changes in LLVM. llvm-svn: 230796
2015-02-28 05:22:50 +08:00
%0 = load i32, i32* %arrayidx, align 4, !dbg !21
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
%cmp3 = icmp sgt i32 %0, 0, !dbg !21
br i1 %cmp3, label %for.body.lr.ph, label %for.end, !dbg !21
for.body.lr.ph: ; preds = %entry.split
br label %for.body, !dbg !22
for.body: ; preds = %for.body.lr.ph, %for.body
%indvar = phi i64 [ 0, %for.body.lr.ph ], [ %indvar.next, %for.body ]
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%arrayidx2 = getelementptr i32, i32* %A, i64 %indvar, !dbg !24
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
%1 = add i64 %indvar, 1, !dbg !24
%inc = trunc i64 %1 to i32, !dbg !21
store i32 0, i32* %arrayidx2, align 4, !dbg !24
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
tail call void @llvm.dbg.value(metadata !{null}, i64 0, metadata !18, metadata !DIExpression()), !dbg !20
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
%arrayidx3 = getelementptr inbounds i32, i32* %arrayidx, i64 %indvar, !dbg !21
%2 = load i32, i32* %arrayidx3, align 4, !dbg !21
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
%cmp = icmp slt i32 %inc, %2, !dbg !21
%indvar.next = add i64 %indvar, 1, !dbg !21
br i1 %cmp, label %for.body, label %for.cond.for.end_crit_edge, !dbg !21
for.cond.for.end_crit_edge: ; preds = %for.body
br label %for.end, !dbg !25
for.end: ; preds = %for.cond.for.end_crit_edge, %entry.split
ret void, !dbg !27
}
Upgrade testcases after LLVM r234181 Until r234181 we were silently upgrading old `@llvm.dbg` intrinsics. Fix testcases in polly that were relying on that. llvm-svn: 234192
2015-04-07 02:25:51 +08:00
declare void @llvm.dbg.declare(metadata, metadata, metadata)
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
Upgrade testcases after LLVM r234181 Until r234181 we were silently upgrading old `@llvm.dbg` intrinsics. Fix testcases in polly that were relying on that. llvm-svn: 234192
2015-04-07 02:25:51 +08:00
declare void @llvm.dbg.value(metadata, i64, metadata, metadata)
Diagnostic: Provide end-user message for non-affine loop bound errors llvm-svn: 215832
2014-08-17 18:09:15 +08:00
attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind readnone }
!llvm.dbg.cu = !{!0}
!llvm.module.flags = !{!10, !11}
!llvm.ident = !{!12}
Update debug metadata after LLVM commits r266445+r266446 llvm-svn: 266473
2016-04-16 04:51:27 +08:00
!0 = distinct !DICompileUnit(language: DW_LANG_C99, producer: "clang version 3.6.0 ", isOptimized: false, emissionKind: 1, file: !1, enums: !2, retainedTypes: !2, globals: !2, imports: !2)
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!1 = !DIFile(filename: "ReportLoopBound-01.c", directory: "test/ScopDetectionDiagnostic/")
Run upgrade script from PR21532 to match LLVM changes Update tests for LLVM assembly format change in r224257 using the script attached to PR21532. I'm hoping this unsticks the bot [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432 llvm-svn: 224269
2014-12-16 04:28:50 +08:00
!2 = !{}
Adjust to debug info metadata format change. Rename variable to retainedNodes. This unbreaks the Polly builds. llvm-svn: 331960
2018-05-10 15:09:10 +08:00
!4 = distinct !DISubprogram(name: "f", line: 1, isLocal: false, isDefinition: true, virtualIndex: 6, flags: DIFlagPrototyped, isOptimized: false, unit: !0, scopeLine: 1, file: !1, scope: !5, type: !6, retainedNodes: !2)
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!5 = !DIFile(filename: "ReportLoopBound-01.c", directory: "test/ScopDetectionDiagnostic/")
!6 = !DISubroutineType(types: !7)
Run upgrade script from PR21532 to match LLVM changes Update tests for LLVM assembly format change in r224257 using the script attached to PR21532. I'm hoping this unsticks the bot [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432 llvm-svn: 224269
2014-12-16 04:28:50 +08:00
!7 = !{null, !8, !9}
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!8 = !DIDerivedType(tag: DW_TAG_pointer_type, size: 64, align: 64, baseType: !9)
!9 = !DIBasicType(tag: DW_TAG_base_type, name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
Run upgrade script from PR21532 to match LLVM changes Update tests for LLVM assembly format change in r224257 using the script attached to PR21532. I'm hoping this unsticks the bot [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432 llvm-svn: 224269
2014-12-16 04:28:50 +08:00
!10 = !{i32 2, !"Dwarf Version", i32 4}
Update Polly tests for the great metadata schema change llvm-svn: 231089
2015-03-04 02:17:26 +08:00
!11 = !{i32 2, !"Debug Info Version", i32 3}
Run upgrade script from PR21532 to match LLVM changes Update tests for LLVM assembly format change in r224257 using the script attached to PR21532. I'm hoping this unsticks the bot [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432 llvm-svn: 224269
2014-12-16 04:28:50 +08:00
!12 = !{!"clang version 3.6.0 "}
Fix polly tests after LLVM IR change in r243774 llvm-svn: 243801
2015-08-01 07:58:50 +08:00
!13 = !DILocalVariable(name: "A", line: 1, arg: 1, scope: !4, file: !5, type: !8)
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!14 = !DILocation(line: 1, column: 12, scope: !4)
Fix polly tests after LLVM IR change in r243774 llvm-svn: 243801
2015-08-01 07:58:50 +08:00
!15 = !DILocalVariable(name: "n", line: 1, arg: 2, scope: !4, file: !5, type: !9)
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!16 = !DILocation(line: 1, column: 21, scope: !4)
Run upgrade script from PR21532 to match LLVM changes Update tests for LLVM assembly format change in r224257 using the script attached to PR21532. I'm hoping this unsticks the bot [1]. [1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432 llvm-svn: 224269
2014-12-16 04:28:50 +08:00
!17 = !{i32 0}
Fix polly tests after LLVM IR change in r243774 llvm-svn: 243801
2015-08-01 07:58:50 +08:00
!18 = !DILocalVariable(name: "i", line: 2, scope: !19, file: !5, type: !9)
Update polly for LLVM rename of debug info metadata with DI* prefix Ran the same rename-md-di-prefix.sh script attached to PR23080 as in LLVM r236120 and CFE r236121. llvm-svn: 236127
2015-04-30 01:02:14 +08:00
!19 = distinct !DILexicalBlock(line: 2, column: 3, file: !1, scope: !4)
!20 = !DILocation(line: 2, column: 12, scope: !19)
!21 = !DILocation(line: 2, column: 8, scope: !19)
!22 = !DILocation(line: 2, column: 8, scope: !23)
!23 = distinct !DILexicalBlock(line: 2, column: 8, file: !1, scope: !19)
!24 = !DILocation(line: 3, column: 5, scope: !19)
!25 = !DILocation(line: 2, column: 8, scope: !26)
!26 = distinct !DILexicalBlock(line: 2, column: 8, file: !1, scope: !19)
!27 = !DILocation(line: 4, column: 1, scope: !4)