maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/polly/test/ScopDetect/parametric-multiply-in-scev...

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

29 lines
756 B
LLVM
Raw Normal View History

[polly] Introduce -polly-print-* passes to replace -analyze. The `opt -analyze` option only works with the legacy pass manager and might be removed in the future, as explained in llvm.org/PR53733. This patch introduced -polly-print-* passes that print what the pass would print with the `-analyze` option and replaces all uses of `-analyze` in the regression tests. There are two exceptions: `CodeGen\single_loop_param_less_equal.ll` and `CodeGen\loop_with_condition_nested.ll` use `-analyze on the `-loops` pass which is not part of Polly. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D120782
2022-03-14 21:39:25 +08:00
; RUN: opt %loadPolly -polly-print-detect -disable-output < %s | FileCheck %s
Do not assume all multi-parameter products are affine As soon as one operand of the product is invalid, the entire product is invalid. This happens for example if one of the operands is not loop-invariant. This fixes http://llvm.org/PR23125 Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com llvm-svn: 234119
2015-04-05 22:57:50 +08:00
; CHECK-NOT: Valid Region
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
define void @blam(float* %A, float* %B) {
bb:
%tmp1 = alloca i64
%tmp2 = shl i64 2, undef
%tmp3 = shl i64 2, undef
%tmp4 = mul nsw i64 %tmp2, %tmp3
br label %loop
loop:
%indvar = phi i64 [ %indvar.next, %loop ], [ 0, %bb ]
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
%gep = getelementptr inbounds i64, i64* %tmp1, i64 %indvar
%tmp12 = load i64, i64* %gep
Do not assume all multi-parameter products are affine As soon as one operand of the product is invalid, the entire product is invalid. This happens for example if one of the operands is not loop-invariant. This fixes http://llvm.org/PR23125 Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com llvm-svn: 234119
2015-04-05 22:57:50 +08:00
%tmp13 = mul nsw i64 %tmp12, %tmp4
%ptr = getelementptr inbounds float, float* %B, i64 %tmp13
%val = load float, float* %ptr
store float %val, float* %A
%indvar.next = add nsw i64 %indvar, 1
br i1 false, label %loop, label %bb21
bb21:
ret void
}