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/read-only-scalars.ll

40 lines
1.1 KiB
LLVM
Raw Normal View History

Do not detect Scops with only one loop. If a region does not have more than one loop, we do not identify it as a Scop in ScopDetection. The main optimizations Polly is currently performing (tiling, preparation for outer-loop vectorization and loop fusion) are unlikely to have a positive impact on individual loops. In some cases, Polly's run-time alias checks or conditional hoisting may still have a positive impact, but those are mostly enabling transformations which LLVM already performs for individual loops. As we do not focus on individual loops, we leave them untouched to not introduce compile time regressions and execution time noise. This results in good compile time reduction (oourafft: -73.99%, smg2000: -56.25%). Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in> Reviewers: grosser Differential Revision: http://reviews.llvm.org/D12268 llvm-svn: 246161
2015-08-28 00:55:18 +08:00
; RUN: opt %loadPolly -polly-analyze-read-only-scalars=false -polly-scops \
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: -analyze < %s | FileCheck %s
Do not detect Scops with only one loop. If a region does not have more than one loop, we do not identify it as a Scop in ScopDetection. The main optimizations Polly is currently performing (tiling, preparation for outer-loop vectorization and loop fusion) are unlikely to have a positive impact on individual loops. In some cases, Polly's run-time alias checks or conditional hoisting may still have a positive impact, but those are mostly enabling transformations which LLVM already performs for individual loops. As we do not focus on individual loops, we leave them untouched to not introduce compile time regressions and execution time noise. This results in good compile time reduction (oourafft: -73.99%, smg2000: -56.25%). Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in> Reviewers: grosser Differential Revision: http://reviews.llvm.org/D12268 llvm-svn: 246161
2015-08-28 00:55:18 +08:00
; RUN: opt %loadPolly -polly-analyze-read-only-scalars=true -polly-scops \
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: -analyze < %s | FileCheck %s \
Do not detect Scops with only one loop. If a region does not have more than one loop, we do not identify it as a Scop in ScopDetection. The main optimizations Polly is currently performing (tiling, preparation for outer-loop vectorization and loop fusion) are unlikely to have a positive impact on individual loops. In some cases, Polly's run-time alias checks or conditional hoisting may still have a positive impact, but those are mostly enabling transformations which LLVM already performs for individual loops. As we do not focus on individual loops, we leave them untouched to not introduce compile time regressions and execution time noise. This results in good compile time reduction (oourafft: -73.99%, smg2000: -56.25%). Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in> Reviewers: grosser Differential Revision: http://reviews.llvm.org/D12268 llvm-svn: 246161
2015-08-28 00:55:18 +08:00
; RUN: -check-prefix=SCALARS
Optionally model read-only scalars Even though read-only accesses to scalars outside of a scop do not need to be modeled to derive valid transformations or to generate valid sequential code, but information about them is useful when we considering memory footprint analysis and/or kernel offloading. llvm-svn: 243981
2015-08-04 21:54:20 +08:00
; CHECK-NOT: Memref_scalar
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
; SCALARS: float MemRef_scalar; // Element size 4
Optionally model read-only scalars Even though read-only accesses to scalars outside of a scop do not need to be modeled to derive valid transformations or to generate valid sequential code, but information about them is useful when we considering memory footprint analysis and/or kernel offloading. llvm-svn: 243981
2015-08-04 21:54:20 +08:00
; SCALARS: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
; SCALARS: { Stmt_stmt1[i0] -> MemRef_scalar[] };
Also build scalar dependences for store instructions While ignoring read-only scalar dependences it was not necessary to consider store instructins, but as store instructions can be the target of a scalar read-only dependency we need to consider them for the construction of scalar read-only dependences. llvm-svn: 246429
2015-08-31 19:15:00 +08:00
; SCALARS: ReadAccess := [Reduction Type: NONE] [Scalar: 1]
; SCALARS: { Stmt_stmt1[i0] -> MemRef_scalar2[] };
Optionally model read-only scalars Even though read-only accesses to scalars outside of a scop do not need to be modeled to derive valid transformations or to generate valid sequential code, but information about them is useful when we considering memory footprint analysis and/or kernel offloading. llvm-svn: 243981
2015-08-04 21:54:20 +08:00
Also build scalar dependences for store instructions While ignoring read-only scalar dependences it was not necessary to consider store instructins, but as store instructions can be the target of a scalar read-only dependency we need to consider them for the construction of scalar read-only dependences. llvm-svn: 246429
2015-08-31 19:15:00 +08:00
define void @foo(float* noalias %A, float* %B, float %scalar, float %scalar2) {
Optionally model read-only scalars Even though read-only accesses to scalars outside of a scop do not need to be modeled to derive valid transformations or to generate valid sequential code, but information about them is useful when we considering memory footprint analysis and/or kernel offloading. llvm-svn: 243981
2015-08-04 21:54:20 +08:00
entry:
br label %loop
loop:
%indvar = phi i64 [0, %entry], [%indvar.next, %loop.backedge]
br label %stmt1
stmt1:
%val = load float, float* %A
%sum = fadd float %val, %scalar
store float %sum, float* %A
Also build scalar dependences for store instructions While ignoring read-only scalar dependences it was not necessary to consider store instructins, but as store instructions can be the target of a scalar read-only dependency we need to consider them for the construction of scalar read-only dependences. llvm-svn: 246429
2015-08-31 19:15:00 +08:00
store float %scalar2, float* %B
Optionally model read-only scalars Even though read-only accesses to scalars outside of a scop do not need to be modeled to derive valid transformations or to generate valid sequential code, but information about them is useful when we considering memory footprint analysis and/or kernel offloading. llvm-svn: 243981
2015-08-04 21:54:20 +08:00
br label %loop.backedge
loop.backedge:
%indvar.next = add i64 %indvar, 1
%cond = icmp sle i64 %indvar, 100
br i1 %cond, label %loop, label %exit
exit:
ret void
}