maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Analysis/ScalarEvolution/limit-depth.ll

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

143 lines
3.9 KiB
LLVM
Raw Normal View History

[SCEV] Use depth limit for trunc analysis Summary: This fixes an extremely long compile time caused by recursive analysis of truncs, which were not previously subject to any depth limits unlike some of the other ops. I decided to use the same control used for sext/zext, since the routines analyzing these are sometimes mutually recursive with the trunc analysis. Reviewers: mkazantsev, sanjoy Subscribers: sanjoy, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58994 llvm-svn: 355949
2019-03-13 02:28:05 +08:00
; RUN: opt -scalar-evolution-max-arith-depth=0 -scalar-evolution-max-cast-depth=0 -analyze -scalar-evolution < %s | FileCheck %s
[ScalarEvolution] Apply Depth limit to getMulExpr This is a fix for PR33292 that shows a case of extremely long compilation of a single .c file with clang, with most time spent within SCEV. We have a mechanism of limiting recursion depth for getAddExpr to avoid long analysis in SCEV. However, there are calls from getAddExpr to getMulExpr and back that do not propagate the info about depth. As result of this, a chain getAddExpr -> ... .> getAddExpr -> getMulExpr -> getAddExpr -> ... -> getAddExpr can be extremely long, with every segment of getAddExpr's being up to max depth long. This leads either to long compilation or crash by stack overflow. We face this situation while analyzing big SCEVs in the test of PR33292. This patch applies the same limit on max expression depth for getAddExpr and getMulExpr. Differential Revision: https://reviews.llvm.org/D33984 llvm-svn: 305463
2017-06-15 19:48:21 +08:00
; Check that depth set to 0 prevents getAddExpr and getMulExpr from making
; transformations in SCEV. We expect the result to be very straightforward.
define void @test_add(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f) {
; CHECK-LABEL: @test_add
; CHECK: %s2 = add i32 %s1, %p3
; CHECK-NEXT: --> (%a + %a + %b + %b + %c + %c + %d + %d + %e + %e + %f + %f)
%tmp0 = add i32 %a, %b
%tmp1 = add i32 %b, %c
%tmp2 = add i32 %c, %d
%tmp3 = add i32 %d, %e
%tmp4 = add i32 %e, %f
%tmp5 = add i32 %f, %a
%p1 = add i32 %tmp0, %tmp3
%p2 = add i32 %tmp1, %tmp4
%p3 = add i32 %tmp2, %tmp5
%s1 = add i32 %p1, %p2
%s2 = add i32 %s1, %p3
ret void
}
define void @test_mul(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f) {
; CHECK-LABEL: @test_mul
; CHECK: %s2 = mul i32 %s1, %p3
; CHECK-NEXT: --> (2 * 3 * 4 * 5 * 6 * 7 * %a * %b * %c * %d * %e * %f)
%tmp0 = mul i32 %a, 2
%tmp1 = mul i32 %b, 3
%tmp2 = mul i32 %c, 4
%tmp3 = mul i32 %d, 5
%tmp4 = mul i32 %e, 6
%tmp5 = mul i32 %f, 7
%p1 = mul i32 %tmp0, %tmp3
%p2 = mul i32 %tmp1, %tmp4
%p3 = mul i32 %tmp2, %tmp5
%s1 = mul i32 %p1, %p2
%s2 = mul i32 %s1, %p3
ret void
}
[SCEV] Use depth limit instead of local cache for SExt and ZExt In rL300494 there was an attempt to deal with excessive compile time on invocations of getSign/ZeroExtExpr using local caching. This approach only helps if we request the same SCEV multiple times throughout recursion. But in the bug PR33431 we see a case where we request different values all the time, so caching does not help and the size of the cache grows enormously. In this patch we remove the local cache for this methods and add the recursion depth limit instead, as we do for arithmetics. This gives us a guarantee that the invocation sequence is limited and reasonably short. Differential Revision: https://reviews.llvm.org/D34273 llvm-svn: 306785
2017-06-30 13:04:09 +08:00
define void @test_sext(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f) {
; CHECK-LABEL: @test_sext
; CHECK: %se2 = sext i64 %iv2.inc to i128
Revert "[SCEV] add no wrap flag for SCEVAddExpr." This reverts r366419 because the analysis performed is within the context of the loop and it's only valid to add wrapping flags to "global" expressions if they're always correct. llvm-svn: 373184
2019-09-30 15:46:52 +08:00
; CHECK-NEXT: --> {(1 + (sext i64 {(sext i32 (1 + %a) to i64),+,1}<nsw><%loop> to i128))<nsw>,+,1}<nsw><%loop2>
[SCEV] Use depth limit instead of local cache for SExt and ZExt In rL300494 there was an attempt to deal with excessive compile time on invocations of getSign/ZeroExtExpr using local caching. This approach only helps if we request the same SCEV multiple times throughout recursion. But in the bug PR33431 we see a case where we request different values all the time, so caching does not help and the size of the cache grows enormously. In this patch we remove the local cache for this methods and add the recursion depth limit instead, as we do for arithmetics. This gives us a guarantee that the invocation sequence is limited and reasonably short. Differential Revision: https://reviews.llvm.org/D34273 llvm-svn: 306785
2017-06-30 13:04:09 +08:00
entry:
br label %loop
loop:
%iv = phi i32 [ %a, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nsw i32 %iv, 1
%cond = icmp sle i32 %iv.inc, 50
br i1 %cond, label %loop, label %between
between:
%se = sext i32 %iv.inc to i64
br label %loop2
loop2:
%iv2 = phi i64 [ %se, %between ], [ %iv2.inc, %loop2 ]
%iv2.inc = add nsw i64 %iv2, 1
%cond2 = icmp sle i64 %iv2.inc, 50
br i1 %cond2, label %loop2, label %exit
exit:
%se2 = sext i64 %iv2.inc to i128
ret void
}
define void @test_zext(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f) {
; CHECK-LABEL: @test_zext
; CHECK: %ze2 = zext i64 %iv2.inc to i128
; CHECK-NEXT: --> {(1 + (zext i64 {7,+,1}<nuw><nsw><%loop> to i128))<nuw><nsw>,+,1}<nuw><%loop2>
entry:
br label %loop
loop:
%iv = phi i32 [ 6, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nsw i32 %iv, 1
%cond = icmp sle i32 %iv.inc, 50
br i1 %cond, label %loop, label %between
between:
%ze = zext i32 %iv.inc to i64
br label %loop2
loop2:
%iv2 = phi i64 [ %ze, %between ], [ %iv2.inc, %loop2 ]
%iv2.inc = add nuw i64 %iv2, 1
%cond2 = icmp sle i64 %iv2.inc, 50
br i1 %cond2, label %loop2, label %exit
exit:
%ze2 = zext i64 %iv2.inc to i128
ret void
}
[SCEV] Use depth limit for trunc analysis Summary: This fixes an extremely long compile time caused by recursive analysis of truncs, which were not previously subject to any depth limits unlike some of the other ops. I decided to use the same control used for sext/zext, since the routines analyzing these are sometimes mutually recursive with the trunc analysis. Reviewers: mkazantsev, sanjoy Subscribers: sanjoy, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58994 llvm-svn: 355949
2019-03-13 02:28:05 +08:00
define void @test_trunc(i32 %a, i32 %b, i32 %c, i32 %d, i32 %e, i32 %f) {
; CHECK-LABEL: @test_trunc
; CHECK: %trunc2 = trunc i64 %iv2.inc to i32
; CHECK-NEXT: --> {(trunc i64 (1 + {7,+,1}<%loop>) to i32),+,1}<%loop2>
entry:
br label %loop
loop:
%iv = phi i128 [ 6, %entry ], [ %iv.inc, %loop ]
%iv.inc = add nsw i128 %iv, 1
%cond = icmp sle i128 %iv.inc, 50
br i1 %cond, label %loop, label %between
between:
%trunc = trunc i128 %iv.inc to i64
br label %loop2
loop2:
%iv2 = phi i64 [ %trunc, %between ], [ %iv2.inc, %loop2 ]
%iv2.inc = add nuw i64 %iv2, 1
%cond2 = icmp sle i64 %iv2.inc, 50
br i1 %cond2, label %loop2, label %exit
exit:
%trunc2 = trunc i64 %iv2.inc to i32
ret void
}
[SCEV] Constant fold MultExpr before applying depth limit. Summary: Users of SCEV reasonably assume that multiplication of two constant SCEVs will in turn be constant. However, that is not always the case: First, we can get here with reached depth limit, and will create MultExpr SCEV `C1 * C2` and cache it. Then, we can get here with the same operands, but with small depth level. But this time we will find existing MultExpr SCEV and return it, instead of expected constant SCEV. This patch changes getMultExpr to not apply depth limit to all constant operands expression, allowing them to be folded. Reviewers: reames, mkazantsev Subscribers: hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79893
2020-05-14 01:55:07 +08:00
; Check that all constant SCEVs are folded regardless depth limit.
define void @test_mul_const(i32 %a) {
; CHECK-LABEL: @test_mul_const
; CHECK: %test3 = mul i32 %test2, 3
; CHECK-NEXT: --> (9 + (3 * (3 * %a)))
; CHECK: %test4 = mul i32 3, 3
; CHECK-NEXT: --> 9 U: [9,10) S: [9,10)
%test = mul i32 3, %a
%test2 = add i32 3, %test
%test3 = mul i32 %test2, 3
%test4 = mul i32 3, 3
ret void
}