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/wraping_signed_expr_0.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

72 lines
2.2 KiB
LLVM
Raw Normal View History

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: opt %loadPolly -polly-scops -analyze < %s | FileCheck %s
Use modulo semantic to generate non-integer-overflow assumptions This will allow to generate non-wrap assumptions for integer expressions that are part of the SCoP. We compare the common isl representation of the expression with one computed with modulo semantic. For all parameter combinations they are not equal we can have integer overflows. The nsw flags are respected when the modulo representation is computed, nuw and nw flags are ignored for now. In order to not increase compile time to much, the non-wrap assumptions are collected in a separate boundary context instead of the assumed context. This helps compile time as the boundary context can become complex and it is therefor not advised to use it in other operations except runtime check generation. However, the assumed context is e.g., used to tighten dependences. While the boundary context might help to tighten the assumed context it is doubtful that it will help in practice (it does not effect lnt much) as the boundary (or no-wrap assumptions) only restrict the very end of the possible value range of parameters. PET uses a different approach to compute the no-wrap context, though lnt runs have shown that this version performs slightly better for us. llvm-svn: 247732
2015-09-16 06:52:53 +08:00
;
; void f(int *A, char N, char p) {
; for (char i = 0; i < N; i++) {
; A[i + 3] = 0;
; }
; }
;
; The wrap function has no inbounds GEP but the nowrap function has. Therefore,
; we will add the assumption that i+1 won't overflow only to the former.
;
; CHECK: Function: wrap
Track assumptions and restrictions separatly In order to speed up compile time and to avoid random timeouts we now separately track assumptions and restrictions. In this context assumptions describe parameter valuations we need and restrictions describe parameter valuations we do not allow. During AST generation we create a runtime check for both, whereas the one for the restrictions is negated before a conjunction is build. Except the In-Bounds assumptions we currently only track restrictions. Differential Revision: http://reviews.llvm.org/D17247 llvm-svn: 262328
2016-03-01 21:06:28 +08:00
; CHECK: Invalid Context:
; CHECK: [N] -> { : N >= 126 }
Use modulo semantic to generate non-integer-overflow assumptions This will allow to generate non-wrap assumptions for integer expressions that are part of the SCoP. We compare the common isl representation of the expression with one computed with modulo semantic. For all parameter combinations they are not equal we can have integer overflows. The nsw flags are respected when the modulo representation is computed, nuw and nw flags are ignored for now. In order to not increase compile time to much, the non-wrap assumptions are collected in a separate boundary context instead of the assumed context. This helps compile time as the boundary context can become complex and it is therefor not advised to use it in other operations except runtime check generation. However, the assumed context is e.g., used to tighten dependences. While the boundary context might help to tighten the assumed context it is doubtful that it will help in practice (it does not effect lnt much) as the boundary (or no-wrap assumptions) only restrict the very end of the possible value range of parameters. PET uses a different approach to compute the no-wrap context, though lnt runs have shown that this version performs slightly better for us. llvm-svn: 247732
2015-09-16 06:52:53 +08:00
;
;
; FIXME: This is a negative test as nowrap should not need an assumed context.
; However %tmp5 in @nowrap is translated to the SCEV <3,+,1><nw><%bb2>
; which lacks the <nsw> flags we would need to avoid runtime checks.
;
; CHECK: Function: nowrap
Track assumptions and restrictions separatly In order to speed up compile time and to avoid random timeouts we now separately track assumptions and restrictions. In this context assumptions describe parameter valuations we need and restrictions describe parameter valuations we do not allow. During AST generation we create a runtime check for both, whereas the one for the restrictions is negated before a conjunction is build. Except the In-Bounds assumptions we currently only track restrictions. Differential Revision: http://reviews.llvm.org/D17247 llvm-svn: 262328
2016-03-01 21:06:28 +08:00
; CHECK: Invalid Context:
Use modulo semantic to generate non-integer-overflow assumptions This will allow to generate non-wrap assumptions for integer expressions that are part of the SCoP. We compare the common isl representation of the expression with one computed with modulo semantic. For all parameter combinations they are not equal we can have integer overflows. The nsw flags are respected when the modulo representation is computed, nuw and nw flags are ignored for now. In order to not increase compile time to much, the non-wrap assumptions are collected in a separate boundary context instead of the assumed context. This helps compile time as the boundary context can become complex and it is therefor not advised to use it in other operations except runtime check generation. However, the assumed context is e.g., used to tighten dependences. While the boundary context might help to tighten the assumed context it is doubtful that it will help in practice (it does not effect lnt much) as the boundary (or no-wrap assumptions) only restrict the very end of the possible value range of parameters. PET uses a different approach to compute the no-wrap context, though lnt runs have shown that this version performs slightly better for us. llvm-svn: 247732
2015-09-16 06:52:53 +08:00
; CHECK-NOT: [N] -> { : }
;
target datalayout = "e-m:e-i8:64-f80:128-n8:16:32:64-S128"
define void @wrap(i32* %A, i8 %N, i8 %p) {
bb:
br label %bb2
bb2: ; preds = %bb7, %bb
%indvars.iv = phi i8 [ %indvars.iv.next, %bb7 ], [ 0, %bb ]
%tmp3 = icmp slt i8 %indvars.iv, %N
br i1 %tmp3, label %bb4, label %bb8
bb4: ; preds = %bb2
%tmp5 = add i8 %indvars.iv, 3
%tmp6 = getelementptr i32, i32* %A, i8 %tmp5
store i32 0, i32* %tmp6, align 4
br label %bb7
bb7: ; preds = %bb4
%indvars.iv.next = add nsw nuw i8 %indvars.iv, 1
br label %bb2
bb8: ; preds = %bb2
ret void
}
define void @nowrap(i32* %A, i8 %N, i8 %p) {
bb:
br label %bb2
bb2: ; preds = %bb7, %bb
%indvars.iv = phi i8 [ %indvars.iv.next, %bb7 ], [ 0, %bb ]
%tmp3 = icmp slt i8 %indvars.iv, %N
br i1 %tmp3, label %bb4, label %bb8
bb4: ; preds = %bb2
%tmp5 = add nsw nuw i8 %indvars.iv, 3
%tmp6 = getelementptr inbounds i32, i32* %A, i8 %tmp5
store i32 0, i32* %tmp6, align 4
br label %bb7
bb7: ; preds = %bb4
%indvars.iv.next = add nsw nuw i8 %indvars.iv, 1
br label %bb2
bb8: ; preds = %bb2
ret void
}