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/PostDominators/pr6047_d.ll

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

32 lines
553 B
LLVM
Raw Normal View History

Fix PR6047 Nodes that had children outside of the post dominator tree (infinite loops) where removed from the post dominator tree. This seems to be wrong. Leave them in the tree. llvm-svn: 93633
2010-01-16 21:38:07 +08:00
; RUN: opt < %s -postdomtree -analyze | FileCheck %s
define internal void @f() {
entry:
br i1 1, label %a, label %b
a:
br label %c
b:
br label %c
c:
br i1 undef, label %bb35, label %bb3.i
bb3.i:
br label %bb3.i
bb35.loopexit3:
br label %bb35
bb35:
ret void
}
[Dominators] Include infinite loops in PostDominatorTree Summary: This patch teaches PostDominatorTree about infinite loops. It is built on top of D29705 by @dberlin which includes a very detailed motivation for this change. What's new is that the patch also teaches the incremental updater how to deal with reverse-unreachable regions and how to properly maintain and verify tree roots. Before that, the incremental algorithm sometimes ended up preserving reverse-unreachable regions after updates that wouldn't appear in the tree if it was constructed from scratch on the same CFG. This patch makes the following assumptions: - A sequence of updates should produce the same tree as a recalculating it. - Any sequence of the same updates should lead to the same tree. - Siblings and roots are unordered. The last two properties are essential to efficiently perform batch updates in the future. When it comes to the first one, we can decide later that the consistency between freshly built tree and an updated one doesn't matter match, as there are many correct ways to pick roots in infinite loops, and to relax this assumption. That should enable us to recalculate postdominators less frequently. This patch is pretty conservative when it comes to incremental updates on reverse-unreachable regions and ends up recalculating the whole tree in many cases. It should be possible to improve the performance in many cases, if we decide that it's important enough. That being said, my experiments showed that reverse-unreachable are very rare in the IR emitted by clang when bootstrapping clang. Here are the statistics I collected by analyzing IR between passes and after each removePredecessor call: ``` # functions: 52283 # samples: 337609 # reverse unreachable BBs: 216022 # BBs: 247840796 Percent reverse-unreachable: 0.08716159869015269 % Max(PercRevUnreachable) in a function: 87.58620689655172 % # > 25 % samples: 471 ( 0.1395104988314885 % samples ) ... in 145 ( 0.27733680163724345 % functions ) ``` Most of the reverse-unreachable regions come from invalid IR where it wouldn't be possible to construct a PostDomTree anyway. I would like to commit this patch in the next week in order to be able to complete the work that depends on it before the end of my internship, so please don't wait long to voice your concerns :). Reviewers: dberlin, sanjoy, grosser, brzycki, davide, chandlerc, hfinkel Reviewed By: dberlin Subscribers: nhaehnle, javed.absar, kparzysz, uabelho, jlebar, hiraditya, llvm-commits, dberlin, david2050 Differential Revision: https://reviews.llvm.org/D35851 llvm-svn: 310940
2017-08-16 02:14:57 +08:00
; CHECK: Inorder PostDominator Tree:
; CHECK-NEXT: [1] <<exit node>>
; CHECK-NEXT: [2] %bb35
; CHECK-NEXT: [3] %bb35.loopexit3
; CHECK-NEXT: [2] %c
; CHECK-NEXT: [3] %a
; CHECK-NEXT: [3] %entry
; CHECK-NEXT: [3] %b
; CHECK-NEXT: [2] %bb3.i