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/scalar.ll

60 lines
1.7 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 < %s | FileCheck %s
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +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"
define void @f(i64* %a, i64 %N) {
entry:
br label %for
for:
%indvar = phi i64 [ 0, %entry ], [ %indvar.next, %for.backedge ]
br label %S1
S1:
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%scevgep1 = getelementptr i64, i64* %a, i64 %indvar
Update Polly tests to handle explicitly typed load changes in LLVM. llvm-svn: 230796
2015-02-28 05:22:50 +08:00
%val = load i64, i64* %scevgep1, align 8
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
br label %S2
S2:
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%scevgep2 = getelementptr i64, i64* %a, i64 %indvar
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
store i64 %val, i64* %scevgep2, align 8
br label %for.backedge
for.backedge:
%indvar.next = add nsw i64 %indvar, 1
%exitcond = icmp eq i64 %indvar.next, %N
br i1 %exitcond, label %return, label %for
return:
ret void
}
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: Arrays {
ScopInfo: Make printing of ScopArrayInfo more similar to declarations in C Memory references are now printed as follows: Old New Scalars: i64 MemRef_val[*] i64 MemRef_val; Arrays: i64 MemRef_A[*][%m][%o][8] i64 MemRef_A[*][%m][%o]; We do not print any more information about the element size in the type. Such information has already been available in a comment after the scalar/array declaration. It was redundant and did not match well with what people were used from C. llvm-svn: 252602
2015-11-10 22:02:54 +08:00
; CHECK: i64 MemRef_a[*];
; CHECK: i64 MemRef_val; [BasePtrOrigin: MemRef_a]
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: }
;
; CHECK: Arrays (Bounds as pw_affs) {
ScopInfo: Make printing of ScopArrayInfo more similar to declarations in C Memory references are now printed as follows: Old New Scalars: i64 MemRef_val[*] i64 MemRef_val; Arrays: i64 MemRef_A[*][%m][%o][8] i64 MemRef_A[*][%m][%o]; We do not print any more information about the element size in the type. Such information has already been available in a comment after the scalar/array declaration. It was redundant and did not match well with what people were used from C. llvm-svn: 252602
2015-11-10 22:02:54 +08:00
; CHECK: i64 MemRef_a[*];
; CHECK: i64 MemRef_val; [BasePtrOrigin: MemRef_a]
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: }
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
; CHECK: Stmt_S1
; CHECK: Domain :=
; CHECK: [N] -> { Stmt_S1[i0] : i0 >= 0 and i0 <= -1 + N };
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] -> { Stmt_S1[i0] -> [i0, 0] };
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
; CHECK: ReadAccess :=
; CHECK: [N] -> { Stmt_S1[i0] -> MemRef_a[i0] };
; CHECK: MustWriteAccess :=
ScopInfo: Scalar accesses are zero dimensional llvm-svn: 205958
2014-04-10 16:38:02 +08:00
; CHECK: [N] -> { Stmt_S1[i0] -> MemRef_val[] };
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
; CHECK: Stmt_S2
; CHECK: Domain :=
; CHECK: [N] -> { Stmt_S2[i0] : i0 >= 0 and i0 <= -1 + N };
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] -> { Stmt_S2[i0] -> [i0, 1] };
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
; CHECK: ReadAccess :=
ScopInfo: Scalar accesses are zero dimensional llvm-svn: 205958
2014-04-10 16:38:02 +08:00
; CHECK: [N] -> { Stmt_S2[i0] -> MemRef_val[] };
Do not track location of scalar dependences in ScopInfo We do not have a use for this information at the moment. If we need this at some point, the "instruction -> access" mapping needs to be enhanced as a single instruction could then possibly perform multiple accesses. This patch allows us to build the polyhedral information for scops with scalar dependences. llvm-svn: 201815
2014-02-21 05:29:09 +08:00
; CHECK: MustWriteAccess :=
; CHECK: [N] -> { Stmt_S2[i0] -> MemRef_a[i0] };