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_only_ivs_2d.ll

51 lines
1.5 KiB
LLVM
Raw Normal View History

ScopDetection: Only detect scops that have at least one read and one write Scops that only read seem generally uninteresting and scops that only write are most likely initializations where there is also little to optimize. To not waste compile time we bail early. Differential Revision: http://reviews.llvm.org/D7735 llvm-svn: 229820
2015-02-19 13:31:07 +08:00
; RUN: opt %loadPolly -polly-detect-unprofitable -polly-scops -analyze -polly-delinearize < %s | FileCheck %s
Add test cases for multi-dimensional variable lengths arrays At the moment we can handle such arrays only by conservatively assuming that each access to such an array may touch any element in the array. It would be great if we could improve Polly/LLVM at some point, such that we can recover the multi-dimensionality of the accesses. llvm-svn: 163619
2012-09-11 22:03:19 +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, double A[n][m]) {
; for (long i = 0; i < n; i++)
; for (long j = 0; j < m; j++)
; A[i][j] = 1.0;
; }
delinearize memory access functions llvm-svn: 205799
2014-04-09 05:20:44 +08:00
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: Assumed Context:
; CHECK: [n, m] -> { : }
delinearize memory access functions llvm-svn: 205799
2014-04-09 05:20:44 +08:00
; CHECK: p0: %n
; CHECK: p1: %m
; CHECK-NOT: p3
; CHECK: Domain
; CHECK: [n, m] -> { Stmt_for_j[i0, i1] : i0 >= 0 and i0 <= -1 + n and i1 >= 0 and i1 <= -1 + m };
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: [n, m] -> { Stmt_for_j[i0, i1] -> [i0, i1] };
delinearize memory access functions llvm-svn: 205799
2014-04-09 05:20:44 +08:00
; CHECK: MustWriteAccess
; CHECK: [n, m] -> { Stmt_for_j[i0, i1] -> MemRef_A[i0, i1] };
Add test cases for multi-dimensional variable lengths arrays At the moment we can handle such arrays only by conservatively assuming that each access to such an array may touch any element in the array. It would be great if we could improve Polly/LLVM at some point, such that we can recover the multi-dimensionality of the accesses. llvm-svn: 163619
2012-09-11 22:03:19 +08:00
define void @foo(i64 %n, i64 %m, double* %A) {
entry:
br label %for.i
for.i:
%i = phi i64 [ 0, %entry ], [ %i.inc, %for.i.inc ]
%tmp = mul nsw i64 %i, %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
Add test cases for multi-dimensional variable lengths arrays At the moment we can handle such arrays only by conservatively assuming that each access to such an array may touch any element in the array. It would be great if we could improve Polly/LLVM at some point, such that we can recover the multi-dimensionality of the accesses. llvm-svn: 163619
2012-09-11 22:03:19 +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, %n
br i1 %i.exitcond, label %end, label %for.i
end:
ret void
}