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/run-time-condition-with-sce...

30 lines
1.0 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-no-early-exit -polly-codegen-isl -S -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
Revert "[Refactor] Cleanup runtime code generation" This reverts commit 215466 (and 215528, a trivial formatting fix). The intention of these commits is a good one, but unfortunately they broke our LNT buildbot: http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-codegen-isl Several of the cleanup changes that have been combined in this 'fixup' are trivial and could probably be committed as obvious changes without risking to break the build. The remaining changes are little and it should be easy to figure out what went wrong. llvm-svn: 215817
2014-08-16 17:09:15 +08:00
; CHECK: %1 = zext i32 %n to i64
Use isl_ast_expr_call to create run-time checks isl recently introduced a new interface to create run-time checks from constraint sets. Use this interface to simplify our run-time check generation. llvm-svn: 230640
2015-02-26 23:21:10 +08:00
; CHECK-NEST: %2 = icmp sge i64 %1, 1
; CHECK-NEST: br label %polly.split_new_and_old
; CHECK: polly.split_new_and_old:
; CHECK-NEXT: br i1 %2, label %polly.start, label %for.body4
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-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @init_array(i32 %n, double* %data) {
entry:
%0 = zext i32 %n to i64
br label %for.body4
for.body4: ; preds = %for.body4, %entry
%indvar1 = phi i64 [ %indvar.next2, %for.body4 ], [ 0, %entry ]
%.moved.to.for.body4 = mul i64 %0, %indvar1
%1 = add i64 %.moved.to.for.body4, 0
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%arrayidx7 = getelementptr double, double* %data, i64 %1
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 undef, double* %arrayidx7, align 8
%indvar.next2 = add i64 %indvar1, 1
br i1 false, label %for.body4, label %for.end10
for.end10: ; preds = %for.body4
ret void
}