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/multi-scop.ll

38 lines
1.4 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-detect -analyze < %s | FileCheck %s
; RUN: opt %loadPolly -polly-detect-unprofitable -polly-scops -analyze < %s
Check scops a second time before working on them In rare cases the modification of one scop can effect the validity of other scops, as code generation of an earlier scop may make the scalar evolution functions derived for later scops less precise. The example that triggered this patch was a scop that contained an 'or' expression as follows: %add13710 = or i32 %j.19, 1 --> {(1 + (4 * %l)),+,2}<nsw><%for.body81> Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This information was not available after the first scop was code generated (or independent-blocks was run on it) and SCEV could not derive a precise SCEV expression any more. This means we could not any more code generate this SCoP. My current understanding is that there is always the risk that an earlier code generation change invalidates later scops. As the example we have seen here is difficult to avoid, we use this occasion to guard us against all such invalidations. This patch "solves" this issue by verifying right before we start working on a detected scop, if this scop is in fact still valid. This adds a certain overhead. However the verification we run is anyways very fast and secondly it is only run on detected scops. So the overhead should not be very large. As a later optimization we could detect scops only on demand, such that we need to run scop-detections always only a single time. This should fix the single last failure in the LLVM test-suite for the new scev-based code generation. llvm-svn: 201593
2014-02-19 02:49:49 +08:00
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
; This test case contains two scops.
define void @test(i32 %l, double* %a) {
entry:
br label %entry.split
entry.split: ; preds = %entry
%shl = shl i32 %l, 2
br i1 false, label %for.body, label %for.end
for.body: ; preds = %for.body, %entry.split
%j.011 = phi i32 [ 0, %entry.split ], [ %add76, %for.body ]
%add76 = add nsw i32 %j.011, 2
br i1 false, label %for.body, label %for.end
for.end: ; preds = %for.body, %entry.split
br i1 undef, label %for.body81, label %for.end170
for.body81: ; preds = %for.body81, %for.end
%j.19 = phi i32 [ %shl, %for.end ], [ %add169, %for.body81 ]
%add13710 = or i32 %j.19, 1
%idxprom138 = sext i32 %add13710 to i64
Update Polly tests to handle explicitly typed gep changes in LLVM llvm-svn: 230784
2015-02-28 03:20:19 +08:00
%arrayidx139 = getelementptr inbounds double, double* %a, i64 %idxprom138
Check scops a second time before working on them In rare cases the modification of one scop can effect the validity of other scops, as code generation of an earlier scop may make the scalar evolution functions derived for later scops less precise. The example that triggered this patch was a scop that contained an 'or' expression as follows: %add13710 = or i32 %j.19, 1 --> {(1 + (4 * %l)),+,2}<nsw><%for.body81> Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This information was not available after the first scop was code generated (or independent-blocks was run on it) and SCEV could not derive a precise SCEV expression any more. This means we could not any more code generate this SCoP. My current understanding is that there is always the risk that an earlier code generation change invalidates later scops. As the example we have seen here is difficult to avoid, we use this occasion to guard us against all such invalidations. This patch "solves" this issue by verifying right before we start working on a detected scop, if this scop is in fact still valid. This adds a certain overhead. However the verification we run is anyways very fast and secondly it is only run on detected scops. So the overhead should not be very large. As a later optimization we could detect scops only on demand, such that we need to run scop-detections always only a single time. This should fix the single last failure in the LLVM test-suite for the new scev-based code generation. llvm-svn: 201593
2014-02-19 02:49:49 +08:00
store double undef, double* %arrayidx139, align 8
%add169 = add nsw i32 %j.19, 2
br i1 false, label %for.body81, label %for.end170
for.end170: ; preds = %for.body81
ret void
}
; CHECK: Valid Region for Scop: entry.split => for.end
Change the RegionSet type to a SetVector This patch changes the RegionSet type used in ScopDetection from a std::set to a llvm::SetVector. The reason for the change is to ensure deterministic output when printing the result of the analysis. We had a windows buildbot failure for the modified test because the output was coming in a different order. Only one test case needed to be modified for this change. We could use CHECK-DAG directives instead of CHECK in the analysis test cases because the actual order of scops does not matter, but I think that change should be done in a separate patch that modifies all the appliciable tests. I simply modified the test to reflect the expected deterministic output. Differential Revision: http://reviews.llvm.org/D5897 llvm-svn: 220423
2014-10-23 04:39:07 +08:00
; CHECK: Valid Region for Scop: for.body81 => for.end170
Check scops a second time before working on them In rare cases the modification of one scop can effect the validity of other scops, as code generation of an earlier scop may make the scalar evolution functions derived for later scops less precise. The example that triggered this patch was a scop that contained an 'or' expression as follows: %add13710 = or i32 %j.19, 1 --> {(1 + (4 * %l)),+,2}<nsw><%for.body81> Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This information was not available after the first scop was code generated (or independent-blocks was run on it) and SCEV could not derive a precise SCEV expression any more. This means we could not any more code generate this SCoP. My current understanding is that there is always the risk that an earlier code generation change invalidates later scops. As the example we have seen here is difficult to avoid, we use this occasion to guard us against all such invalidations. This patch "solves" this issue by verifying right before we start working on a detected scop, if this scop is in fact still valid. This adds a certain overhead. However the verification we run is anyways very fast and secondly it is only run on detected scops. So the overhead should not be very large. As a later optimization we could detect scops only on demand, such that we need to run scop-detections always only a single time. This should fix the single last failure in the LLVM test-suite for the new scev-based code generation. llvm-svn: 201593
2014-02-19 02:49:49 +08:00