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/invariant_load_ptr_ptr_noal...

59 lines
1.9 KiB
LLVM
Raw Normal View History

[tests] Force invariant load hoisting for test cases that need it This will make it easier to switch the default of Polly's invariant load hoisting strategy and also makes it very clear that these test cases indeed require invariant code hoisting to work. llvm-svn: 278667
2016-08-15 21:27:49 +08:00
; RUN: opt %loadPolly -tbaa -polly-scops -polly-invariant-load-hoisting=true -polly-ignore-aliasing \
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: -analyze < %s | FileCheck %s
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
;
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
; Note: The order of the invariant accesses is important because A is the
; base pointer of tmp3 and we will generate code in the same order as
; the invariant accesses are listed here.
;
; CHECK: Invariant Accesses: {
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK: MemRef_A[42]
; CHECK: ReadAccess := [Reduction Type: NONE] [Scalar: 0]
; CHECK: MemRef_tmp3[32]
; CHECK: }
;
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: Arrays {
ScopInfo: Make printing of ScopArrayInfo more similar to declarations in C Memory references are now printed as follows: Old New Scalars: i64 MemRef_val[*] i64 MemRef_val; Arrays: i64 MemRef_A[*][%m][%o][8] i64 MemRef_A[*][%m][%o]; We do not print any more information about the element size in the type. Such information has already been available in a comment after the scalar/array declaration. It was redundant and did not match well with what people were used from C. llvm-svn: 252602
2015-11-10 22:02:54 +08:00
; CHECK: i32** MemRef_A[*];
; CHECK: i32* MemRef_tmp3[*]; [BasePtrOrigin: MemRef_A]
; CHECK: i32 MemRef_tmp5[*]; [BasePtrOrigin: MemRef_tmp3]
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: }
;
; CHECK: Arrays (Bounds as pw_affs) {
ScopInfo: Make printing of ScopArrayInfo more similar to declarations in C Memory references are now printed as follows: Old New Scalars: i64 MemRef_val[*] i64 MemRef_val; Arrays: i64 MemRef_A[*][%m][%o][8] i64 MemRef_A[*][%m][%o]; We do not print any more information about the element size in the type. Such information has already been available in a comment after the scalar/array declaration. It was redundant and did not match well with what people were used from C. llvm-svn: 252602
2015-11-10 22:02:54 +08:00
; CHECK: i32** MemRef_A[*];
; CHECK: i32* MemRef_tmp3[*]; [BasePtrOrigin: MemRef_A]
; CHECK: i32 MemRef_tmp5[*]; [BasePtrOrigin: MemRef_tmp3]
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
; CHECK: }
;
; void f(int ***A) {
; for (int i = 0; i < 1024; i++)
; A[42][32][i] = 0;
; }
;
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
define void @f(i32*** %A) {
bb:
br label %bb1
bb1: ; preds = %bb7, %bb
%indvars.iv = phi i64 [ %indvars.iv.next, %bb7 ], [ 0, %bb ]
%exitcond = icmp ne i64 %indvars.iv, 1024
br i1 %exitcond, label %bb2, label %bb8
bb2: ; preds = %bb1
%tmp = getelementptr inbounds i32**, i32*** %A, i64 42
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
%tmp3 = load i32**, i32*** %tmp, align 8
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
%tmp4 = getelementptr inbounds i32*, i32** %tmp3, i64 32
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
%tmp5 = load i32*, i32** %tmp4, align 8
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
%tmp6 = getelementptr inbounds i32, i32* %tmp5, i64 %indvars.iv
Allow invariant loads in the SCoP description This patch allows invariant loads to be used in the SCoP description, e.g., as loop bounds, conditions or in memory access functions. First we collect "required invariant loads" during SCoP detection that would otherwise make an expression we care about non-affine. To this end a new level of abstraction was introduced before SCEVValidator::isAffineExpr() namely ScopDetection::isAffine() and ScopDetection::onlyValidRequiredInvariantLoads(). Here we can decide if we want a load inside the region to be optimistically assumed invariant or not. If we do, it will be marked as required and in the SCoP generation we bail if it is actually not invariant. If we don't it will be a non-affine expression as before. At the moment we optimistically assume all "hoistable" (namely non-loop-carried) loads to be invariant. This causes us to expand some SCoPs and dismiss them later but it also allows us to detect a lot we would dismiss directly if we would ask e.g., AliasAnalysis::canBasicBlockModify(). We also allow potential aliases between optimistically assumed invariant loads and other pointers as our runtime alias checks are sound in case the loads are actually invariant. Together with the invariant checks this combination allows to handle a lot more than LICM can. The code generation of the invariant loads had to be extended as we can now have dependences between parameters and invariant (hoisted) loads as well as the other way around, e.g., test/Isl/CodeGen/invariant_load_parameters_cyclic_dependence.ll First, it is important to note that we cannot have real cycles but only dependences from a hoisted load to a parameter and from another parameter to that hoisted load (and so on). To handle such cases we materialize llvm::Values for parameters that are referred by a hoisted load on demand and then materialize the remaining parameters. Second, there are new kinds of dependences between hoisted loads caused by the constraints on their execution. If a hoisted load is conditionally executed it might depend on the value of another hoisted load. To deal with such situations we sort them already in the ScopInfo such that they can be generated in the order they are listed in the Scop::InvariantAccesses list (see compareInvariantAccesses). The dependences between hoisted loads caused by indirect accesses are handled the same way as before. llvm-svn: 249607
2015-10-08 04:17:36 +08:00
store i32 0, i32* %tmp6, align 4
Link ScopArrayInfo objects We will record if a SAI is the base of another SAI or derived from it. This will allow to reason about indirect base pointers later on and allows a clearer picture of indirection also in the SCoP dump. llvm-svn: 245584
2015-08-21 02:04:22 +08:00
br label %bb7
bb7: ; preds = %bb2
%indvars.iv.next = add nuw nsw i64 %indvars.iv, 1
br label %bb1
bb8: ; preds = %bb1
ret void
}