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/multidim_2d_outer_parametri...

61 lines
1.8 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 -polly-scops -analyze -polly-delinearize < %s | FileCheck %s
Derive run-time conditions for delinearization As our delinearization works optimistically, we need in some cases run-time checks that verify our optimistic assumptions. A simple example is the following code: void foo(long n, long m, long o, double A[n][m][o]) { for (long i = 0; i < 100; i++) for (long j = 0; j < 150; j++) for (long k = 0; k < 200; k++) A[i][j][k] = 1.0; } After clang linearized the access to A and we delinearized it again to A[i][j][k] we need to ensure that we do not access the delinearized array out of bounds (this information is not available in LLVM-IR). Hence, we need to verify the following constraints at run-time: CHECK: Assumed Context: CHECK: [o, m] -> { : m >= 150 and o >= 200 } llvm-svn: 212198
2014-07-03 01:47:48 +08:00
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
; Derived from the following code:
;
; void foo(long n, long m, long p, double A[n][m]) {
; for (long i = 0; i < 100; i++)
; for (long j = 0; j < m; j++)
; A[i+p][j] = 1.0;
; }
; CHECK: Assumed 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: [m, p] -> { : p <= 9223372036854775708 }
Derive run-time conditions for delinearization As our delinearization works optimistically, we need in some cases run-time checks that verify our optimistic assumptions. A simple example is the following code: void foo(long n, long m, long o, double A[n][m][o]) { for (long i = 0; i < 100; i++) for (long j = 0; j < 150; j++) for (long k = 0; k < 200; k++) A[i][j][k] = 1.0; } After clang linearized the access to A and we delinearized it again to A[i][j][k] we need to ensure that we do not access the delinearized array out of bounds (this information is not available in LLVM-IR). Hence, we need to verify the following constraints at run-time: CHECK: Assumed Context: CHECK: [o, m] -> { : m >= 150 and o >= 200 } llvm-svn: 212198
2014-07-03 01:47:48 +08:00
; CHECK: p0: %m
; CHECK: p1: %p
; CHECK: Statements {
; CHECK: Stmt_for_j
; CHECK: Domain :=
Traverse the SCoP to compute non-loop-carried domain conditions In order to compute domain conditions for conditionals we will now traverse the region in the ScopInfo once and build the domains for each block in the region. The SCoP statements can then use these constraints when they build their domain. The reason behind this change is twofold: 1) This removes a big chunk of preprocessing logic from the TempScopInfo, namely the Conditionals we used to build there. Additionally to moving this logic it is also simplified. Instead of walking the dominance tree up for each basic block in the region (as we did before), we now traverse the region only once in order to collect the domain conditions. 2) This is the first step towards the isl based domain creation. The second step will traverse the region similar to this step, however it will propagate back edge conditions. Once both are in place this conditional handling will allow multiple exit loops additional logic. Reviewers: grosser Differential Revision: http://reviews.llvm.org/D12428 llvm-svn: 246398
2015-08-31 05:13:53 +08:00
; CHECK: [m, p] -> { Stmt_for_j[i0, i1] :
; CHECK-DAG: i0 >= 0
; CHECK-DAG: and
; CHECK-DAG: i0 <= 99
; CHECK-DAG: and
; CHECK-DAG: i1 >= 0
; CHECK-DAG: and
; CHECK-DAG: i1 <= -1 + m
; CHECK: }
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 :=
[NFC] Drop the "scattering" tuple name llvm-svn: 227801
2015-02-02 21:45:54 +08:00
; CHECK: [m, p] -> { Stmt_for_j[i0, i1] -> [i0, i1] };
Derive run-time conditions for delinearization As our delinearization works optimistically, we need in some cases run-time checks that verify our optimistic assumptions. A simple example is the following code: void foo(long n, long m, long o, double A[n][m][o]) { for (long i = 0; i < 100; i++) for (long j = 0; j < 150; j++) for (long k = 0; k < 200; k++) A[i][j][k] = 1.0; } After clang linearized the access to A and we delinearized it again to A[i][j][k] we need to ensure that we do not access the delinearized array out of bounds (this information is not available in LLVM-IR). Hence, we need to verify the following constraints at run-time: CHECK: Assumed Context: CHECK: [o, m] -> { : m >= 150 and o >= 200 } llvm-svn: 212198
2014-07-03 01:47:48 +08:00
; CHECK: MustWriteAccess := [Reduction Type: NONE]
; CHECK: [m, p] -> { Stmt_for_j[i0, i1] -> MemRef_A[p + i0, i1] };
; CHECK: }
define void @foo(i64 %n, i64 %m, i64 %p, double* %A) {
entry:
br label %for.i
for.i:
%i = phi i64 [ 0, %entry ], [ %i.inc, %for.i.inc ]
%add = add nsw i64 %i, %p
%tmp = mul nsw i64 %add, %m
br label %for.j
for.j:
%j = phi i64 [ 0, %for.i ], [ %j.inc, %for.j ]
%vlaarrayidx.sum = add i64 %j, %tmp
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 double, double* %A, i64 %vlaarrayidx.sum
Derive run-time conditions for delinearization As our delinearization works optimistically, we need in some cases run-time checks that verify our optimistic assumptions. A simple example is the following code: void foo(long n, long m, long o, double A[n][m][o]) { for (long i = 0; i < 100; i++) for (long j = 0; j < 150; j++) for (long k = 0; k < 200; k++) A[i][j][k] = 1.0; } After clang linearized the access to A and we delinearized it again to A[i][j][k] we need to ensure that we do not access the delinearized array out of bounds (this information is not available in LLVM-IR). Hence, we need to verify the following constraints at run-time: CHECK: Assumed Context: CHECK: [o, m] -> { : m >= 150 and o >= 200 } llvm-svn: 212198
2014-07-03 01:47:48 +08:00
store double 1.0, double* %arrayidx
%j.inc = add nsw i64 %j, 1
%j.exitcond = icmp eq i64 %j.inc, %m
br i1 %j.exitcond, label %for.i.inc, label %for.j
for.i.inc:
%i.inc = add nsw i64 %i, 1
%i.exitcond = icmp eq i64 %i.inc, 100
br i1 %i.exitcond, label %end, label %for.i
end:
ret void
}