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/parameter-constant-division.ll

95 lines
5.1 KiB
LLVM
Raw Normal View History

[tests] Force invariant load hoisting for test cases that need it II llvm-svn: 278669
2016-08-15 21:58:16 +08:00
; RUN: opt %loadPolly -polly-scops \
[test] Correct spelling in test case and explicitly enable invariant load hoisting for this test case. llvm-svn: 278668
2016-08-15 21:58:04 +08:00
; RUN: -polly-invariant-load-hoisting=true \
; RUN: -analyze -S < %s | FileCheck %s
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
;
; CHECK: Invariant Accesses: {
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
; CHECK-NEXT: { Stmt_land_lhs_true563[] -> MemRef_tmp0[809] };
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_fs[5] };
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_fs[7] };
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_tmp8[813] };
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_tmp3[813] };
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_tmp5[813] };
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
; CHECK-NEXT: { Stmt_if_then570[] -> MemRef_tmp3[812] };
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
; CHECK-NEXT: Execution Context: { : }
; CHECK-NEXT: }
;
; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
%struct.frame_store = type { i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, %struct.picture*, %struct.picture*, %struct.picture* }
%struct.picture = type { i32, i32, i32, i32, i32, i32, [6 x [33 x i64]], [6 x [33 x i64]], [6 x [33 x i64]], [6 x [33 x i64]], i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i16**, i16*, i16*, i16**, i16**, i16***, i8*, i16***, i64***, i64***, i16****, i8**, i8**, %struct.picture*, %struct.picture*, %struct.picture*, i32, i32, i32, i32, i32, i32, i32 }
; Function Attrs: nounwind uwtable
define void @dpb_split_field(%struct.frame_store* %fs) #0 {
entry:
%frame = getelementptr inbounds %struct.frame_store, %struct.frame_store* %fs, i64 0, i32 10
br label %for.cond538.preheader.lr.ph
for.cond538.preheader.lr.ph: ; preds = %entry
%bottom_field578 = getelementptr inbounds %struct.frame_store, %struct.frame_store* %fs, i64 0, i32 12
br label %for.cond538.preheader
for.cond538.preheader: ; preds = %for.inc912, %for.cond538.preheader.lr.ph
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
%tmp0 = phi %struct.picture* [ undef, %for.cond538.preheader.lr.ph ], [ %tmp11, %for.inc912 ]
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
br i1 undef, label %land.lhs.true563, label %for.inc912
land.lhs.true563: ; preds = %for.cond538.preheader
%div552 = sdiv i32 0, 16
%div554 = sdiv i32 0, 4
%mul555 = mul i32 %div552, %div554
%rem558 = srem i32 0, 2
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
%tmp9a = add i32 %mul555, 0
%tmp10a = shl i32 %tmp9a, 1
%add559 = add i32 %tmp10a, %rem558
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
%idxprom564 = sext i32 %add559 to i64
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
%mb_field566 = getelementptr inbounds %struct.picture, %struct.picture* %tmp0, i64 0, i32 31
%tmp1 = load i8*, i8** %mb_field566, align 8
%arrayidx567 = getelementptr inbounds i8, i8* %tmp1, i64 %idxprom564
%tmp2 = load i8, i8* %arrayidx567, align 1
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
store i8 0, i8* %arrayidx567
br i1 false, label %if.end908, label %if.then570
if.then570: ; preds = %land.lhs.true563
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
%tmp3 = load %struct.picture*, %struct.picture** %frame, align 8
%mv = getelementptr inbounds %struct.picture, %struct.picture* %tmp3, i64 0, i32 35
%tmp4 = load i16****, i16***** %mv, align 8
%tmp5 = load %struct.picture*, %struct.picture** %bottom_field578, align 8
%mv612 = getelementptr inbounds %struct.picture, %struct.picture* %tmp5, i64 0, i32 35
%tmp6 = load i16****, i16***** %mv612, align 8
%arrayidx647 = getelementptr inbounds i16***, i16**** %tmp4, i64 1
%ref_id726 = getelementptr inbounds %struct.picture, %struct.picture* %tmp3, i64 0, i32 34
%tmp7 = load i64***, i64**** %ref_id726, align 8
%arrayidx746 = getelementptr inbounds i64**, i64*** %tmp7, i64 5
%tmp8 = load %struct.picture*, %struct.picture** %frame, align 8
%mv783 = getelementptr inbounds %struct.picture, %struct.picture* %tmp8, i64 0, i32 35
%tmp9 = load i16****, i16***** %mv783, align 8
%arrayidx804 = getelementptr inbounds i16***, i16**** %tmp9, i64 1
%tmp10 = load i16***, i16**** %arrayidx804, align 8
%arrayidx805 = getelementptr inbounds i16**, i16*** %tmp10, i64 0
store i16*** %tmp10, i16**** %arrayidx804
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
br label %if.end908
if.end908: ; preds = %if.then570, %land.lhs.true563
br label %for.inc912
for.inc912: ; preds = %if.end908, %for.cond538.preheader
[tests] Ensure all test cases use named variables This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
2017-04-29 05:16:29 +08:00
%tmp11 = phi %struct.picture* [ %tmp0, %for.cond538.preheader ], [ undef, %if.end908 ]
[FIX] Handle multiplications in the SCEVAffinator again If ScalarEvolution cannot look through some expression but we do, it might happen that a multiplication will arrive at the SCEVAffinator::visitMulExpr. While we could always try to improve the extractConstantFactor function we might still miss something, thus we reintroduce the code to generate multiplicative piecewise-affine functions as a fall-back. llvm-svn: 265777
2016-04-08 18:27:40 +08:00
br i1 undef, label %for.cond538.preheader, label %for.cond1392.preheader
for.cond1392.preheader: ; preds = %for.inc912
ret void
}