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

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

80 lines
2.0 KiB
LLVM
Raw Normal View History

[DeLICM] Add regression tests for DeLICM reject cases. These tests were not included in the main DeLICM commit. These check the cases where zone analysis cannot be successful because of assumption violations. We use the LLVM optimization remark infrastructure as it seems to be the best fit for this kind of messages. I tried to make use if the OptimizationRemarkEmitter. However, it would insert additional function passes into the pass manager to get the hotness information. The pass manager would insert them between the flatten pass and delicm, causing the ScopInfo with the flattened schedule being thrown away. Differential Revision: https://reviews.llvm.org/D30253 llvm-svn: 295846
2017-02-22 23:14:08 +08:00
; RUN: opt %loadPolly -polly-delicm -analyze -pass-remarks-analysis=polly-delicm -polly-delicm-max-ops=1 < %s 2>&1 | FileCheck %s
Fix isl out-of-quota errors affecting later quota guards. If an out-of-quota error occurred, the last error would be isl_error_quota unless a different error occured. We typically check whether the max-operations occured by comparing to that error value after leaving the quota guard. This would check whether there ever was a quota-error, not just in the last quota guards. The observable bug occurred if the max-operations limit was reached in DeLICM, and if -polly-dependences-computout=0, DependenceInfo would think that the quota for computing dependencies was the reason, i.e., fail the operation even if the calculation itself was successful. Fix by reseting the last error to isl_error_none when entering a quota guard, signaling that no quota error occured unless in the guard's scope. llvm-svn: 321329
2017-12-22 09:10:31 +08:00
; RUN: opt %loadPolly -polly-delicm -polly-dependences -analyze -polly-delicm-max-ops=1 -polly-dependences-computeout=0 < %s | FileCheck %s -check-prefix=DEP
[DeLICM] Add regression tests for DeLICM reject cases. These tests were not included in the main DeLICM commit. These check the cases where zone analysis cannot be successful because of assumption violations. We use the LLVM optimization remark infrastructure as it seems to be the best fit for this kind of messages. I tried to make use if the OptimizationRemarkEmitter. However, it would insert additional function passes into the pass manager to get the hotness information. The pass manager would insert them between the flatten pass and delicm, causing the ScopInfo with the flattened schedule being thrown away. Differential Revision: https://reviews.llvm.org/D30253 llvm-svn: 295846
2017-02-22 23:14:08 +08:00
;
; void func(double *A) {
; for (int j = 0; j < 2; j += 1) { /* outer */
; double phi = 0.0;
; for (int i = 0; i < 4; i += 1) /* reduction */
; phi += 4.2;
; A[j] = phi;
; }
; }
;
define void @func(double* noalias nonnull %A) {
entry:
br label %outer.preheader
outer.preheader:
br label %outer.for
outer.for:
%j = phi i32 [0, %outer.preheader], [%j.inc, %outer.inc]
%j.cmp = icmp slt i32 %j, 2
br i1 %j.cmp, label %reduction.preheader, label %outer.exit
reduction.preheader:
br label %reduction.for
reduction.for:
%i = phi i32 [0, %reduction.preheader], [%i.inc, %reduction.inc]
%phi = phi double [0.0, %reduction.preheader], [%add, %reduction.inc]
%i.cmp = icmp slt i32 %i, 4
br i1 %i.cmp, label %body, label %reduction.exit
body:
%add = fadd double %phi, 4.2
br label %reduction.inc
reduction.inc:
%i.inc = add nuw nsw i32 %i, 1
br label %reduction.for
reduction.exit:
%A_idx = getelementptr inbounds double, double* %A, i32 %j
store double %phi, double* %A_idx
br label %outer.inc
outer.inc:
%j.inc = add nuw nsw i32 %j, 1
br label %outer.for
outer.exit:
br label %return
return:
ret void
}
; CHECK: maximal number of operations exceeded during zone analysis
Fix isl out-of-quota errors affecting later quota guards. If an out-of-quota error occurred, the last error would be isl_error_quota unless a different error occured. We typically check whether the max-operations occured by comparing to that error value after leaving the quota guard. This would check whether there ever was a quota-error, not just in the last quota guards. The observable bug occurred if the max-operations limit was reached in DeLICM, and if -polly-dependences-computout=0, DependenceInfo would think that the quota for computing dependencies was the reason, i.e., fail the operation even if the calculation itself was successful. Fix by reseting the last error to isl_error_none when entering a quota guard, signaling that no quota error occured unless in the guard's scope. llvm-svn: 321329
2017-12-22 09:10:31 +08:00
; Check that even if the quota was exceeded in DeLICM, DependenceInfo is still
; successfull since it uses a different operations counter.
;
; DEP: RAW dependences:
; DEP-NOT: n/a
; DEP: WAR dependences:
; DEP-NOT: n/a
; DEP: WAW dependences:
; DEP-NOT: n/a
; DEP: Reduction dependences:
; DEP-NOT: n/a
; DEP: Transitive closure of reduction dependences: