maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/Isl/CodeGen/OpenMP/loop-body-references-outer-...

66 lines
2.3 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 -basicaa -polly-parallel -polly-parallel-force -polly-ast -analyze < %s | FileCheck %s -check-prefix=AST
; RUN: opt %loadPolly -polly-detect-unprofitable -basicaa -polly-parallel -polly-parallel-force -polly-codegen-isl -S -verify-dom-info < %s | FileCheck %s -check-prefix=IR
; RUN: opt %loadPolly -polly-detect-unprofitable -basicaa -polly-parallel -polly-parallel-force -polly-codegen-isl -S -verify-dom-info < %s | FileCheck %s -check-prefix=IR
Add OpenMP code generation to isl backend This backend supports besides the classical code generation the upcoming SCEV based code generation (which the existing CLooG backend does not support robustly). OpenMP code generation in the isl backend benefits from our run-time alias checks such that the set of loops that can possibly be parallelized is a lot larger. The code was tested on LNT. We do not regress on builds without -polly-parallel. When using -polly-parallel most tests work flawlessly, but a few issues still remain and will be addressed in follow up commits. SCEV/non-SCEV codegen: - Compile time failure in ldecod and TimberWolfMC due a problem in our run-time alias check generation triggered by pointers that escape through the OpenMP subfunction (OpenMP specific). - Several execution time failures. Due to the larger set of loops that we now parallelize (compared to the classical code generation), we currently run into some timeouts in tests with a lot loops that have a low trip count and are slowed down by parallelizing them. SCEV only: - One existing failure in lencod due to llvm.org/PR21204 (not OpenMP specific) OpenMP code generation is the last feature that was only available in the CLooG backend. With the isl backend being the only one supporting features such as run-time alias checks and delinearization, we will soon switch to use the isl ast generator by the default and subsequently remove our dependency on CLooG. http://reviews.llvm.org/D5517 llvm-svn: 222088
2014-11-16 05:32:53 +08:00
; The interesting part of this test case is the instruction:
; %tmp = bitcast i8* %call to i64**
; which is not part of the scop. In the SCEV based code generation not '%tmp',
; but %call is a parameter of the SCoP and we need to make sure its value is
; properly forwarded to the subfunction.
; AST: #pragma omp parallel for
Drop all constant scheduling dimensions Schedule dimensions that have the same constant value accross all statements do not carry any information, but due to the increased dimensionality of the schedule cost compile time. To not pay this cost, we remove constant dimensions if possible. llvm-svn: 225067
2015-01-02 07:01:11 +08:00
; AST: for (int c0 = 0; c0 < cols; c0 += 1)
; AST: Stmt_for_body(c0);
Add OpenMP code generation to isl backend This backend supports besides the classical code generation the upcoming SCEV based code generation (which the existing CLooG backend does not support robustly). OpenMP code generation in the isl backend benefits from our run-time alias checks such that the set of loops that can possibly be parallelized is a lot larger. The code was tested on LNT. We do not regress on builds without -polly-parallel. When using -polly-parallel most tests work flawlessly, but a few issues still remain and will be addressed in follow up commits. SCEV/non-SCEV codegen: - Compile time failure in ldecod and TimberWolfMC due a problem in our run-time alias check generation triggered by pointers that escape through the OpenMP subfunction (OpenMP specific). - Several execution time failures. Due to the larger set of loops that we now parallelize (compared to the classical code generation), we currently run into some timeouts in tests with a lot loops that have a low trip count and are slowed down by parallelizing them. SCEV only: - One existing failure in lencod due to llvm.org/PR21204 (not OpenMP specific) OpenMP code generation is the last feature that was only available in the CLooG backend. With the isl backend being the only one supporting features such as run-time alias checks and delinearization, we will soon switch to use the isl ast generator by the default and subsequently remove our dependency on CLooG. http://reviews.llvm.org/D5517 llvm-svn: 222088
2014-11-16 05:32:53 +08:00
; IR: @foo.polly.subfn
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @foo(i64 %cols, i8* noalias %call) {
entry:
%tmp = bitcast i8* %call to i64**
br label %for.body
for.body:
%indvar = phi i64 [ %indvar.next, %for.body ], [ 0, %entry ]
%arrayidx = getelementptr inbounds i64** %tmp, i64 0
%tmp1 = load i64** %arrayidx, align 8
%arrayidx.2 = getelementptr inbounds i64* %tmp1, i64 %indvar
store i64 1, i64* %arrayidx.2, align 4
%indvar.next = add nsw i64 %indvar, 1
%cmp = icmp slt i64 %indvar.next, %cols
br i1 %cmp, label %for.body, label %end
end:
ret void
}
; Another variation of this test case, now with even more of the index
; expression defined outside of the scop.
; AST: #pragma omp parallel for
Drop all constant scheduling dimensions Schedule dimensions that have the same constant value accross all statements do not carry any information, but due to the increased dimensionality of the schedule cost compile time. To not pay this cost, we remove constant dimensions if possible. llvm-svn: 225067
2015-01-02 07:01:11 +08:00
; AST: for (int c0 = 0; c0 < cols; c0 += 1)
; AST: Stmt_for_body(c0);
Add OpenMP code generation to isl backend This backend supports besides the classical code generation the upcoming SCEV based code generation (which the existing CLooG backend does not support robustly). OpenMP code generation in the isl backend benefits from our run-time alias checks such that the set of loops that can possibly be parallelized is a lot larger. The code was tested on LNT. We do not regress on builds without -polly-parallel. When using -polly-parallel most tests work flawlessly, but a few issues still remain and will be addressed in follow up commits. SCEV/non-SCEV codegen: - Compile time failure in ldecod and TimberWolfMC due a problem in our run-time alias check generation triggered by pointers that escape through the OpenMP subfunction (OpenMP specific). - Several execution time failures. Due to the larger set of loops that we now parallelize (compared to the classical code generation), we currently run into some timeouts in tests with a lot loops that have a low trip count and are slowed down by parallelizing them. SCEV only: - One existing failure in lencod due to llvm.org/PR21204 (not OpenMP specific) OpenMP code generation is the last feature that was only available in the CLooG backend. With the isl backend being the only one supporting features such as run-time alias checks and delinearization, we will soon switch to use the isl ast generator by the default and subsequently remove our dependency on CLooG. http://reviews.llvm.org/D5517 llvm-svn: 222088
2014-11-16 05:32:53 +08:00
; IR: @bar.polly.subfn
define void @bar(i64 %cols, i8* noalias %call) {
entry:
%tmp = bitcast i8* %call to i64**
%arrayidx = getelementptr inbounds i64** %tmp, i64 0
br label %for.body
for.body:
%indvar = phi i64 [ %indvar.next, %for.body ], [ 0, %entry ]
%tmp1 = load i64** %arrayidx, align 8
%arrayidx.2 = getelementptr inbounds i64* %tmp1, i64 %indvar
store i64 1, i64* %arrayidx.2, align 4
%indvar.next = add nsw i64 %indvar, 1
%cmp = icmp slt i64 %indvar.next, %cols
br i1 %cmp, label %for.body, label %end
end:
ret void
}