1/* Generic dominator tree walker
2   Copyright (C) 2003-2015 Free Software Foundation, Inc.
3   Contributed by Diego Novillo <dnovillo@redhat.com>
4
5This file is part of GCC.
6
7GCC is free software; you can redistribute it and/or modify
8it under the terms of the GNU General Public License as published by
9the Free Software Foundation; either version 3, or (at your option)
10any later version.
11
12GCC is distributed in the hope that it will be useful,
13but WITHOUT ANY WARRANTY; without even the implied warranty of
14MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
15GNU General Public License for more details.
16
17You should have received a copy of the GNU General Public License
18along with GCC; see the file COPYING3.  If not see
19<http://www.gnu.org/licenses/>.  */
20
21#include "config.h"
22#include "system.h"
23#include "coretypes.h"
24#include "tm.h"
25#include "predict.h"
26#include "vec.h"
27#include "hashtab.h"
28#include "hash-set.h"
29#include "machmode.h"
30#include "hard-reg-set.h"
31#include "input.h"
32#include "function.h"
33#include "dominance.h"
34#include "cfg.h"
35#include "cfganal.h"
36#include "basic-block.h"
37#include "domwalk.h"
38#include "sbitmap.h"
39
40/* This file implements a generic walker for dominator trees.
41
42  To understand the dominator walker one must first have a grasp of dominators,
43  immediate dominators and the dominator tree.
44
45  Dominators
46    A block B1 is said to dominate B2 if every path from the entry to B2 must
47    pass through B1.  Given the dominance relationship, we can proceed to
48    compute immediate dominators.  Note it is not important whether or not
49    our definition allows a block to dominate itself.
50
51  Immediate Dominators:
52    Every block in the CFG has no more than one immediate dominator.  The
53    immediate dominator of block BB must dominate BB and must not dominate
54    any other dominator of BB and must not be BB itself.
55
56  Dominator tree:
57    If we then construct a tree where each node is a basic block and there
58    is an edge from each block's immediate dominator to the block itself, then
59    we have a dominator tree.
60
61
62  [ Note this walker can also walk the post-dominator tree, which is
63    defined in a similar manner.  i.e., block B1 is said to post-dominate
64    block B2 if all paths from B2 to the exit block must pass through
65    B1.  ]
66
67  For example, given the CFG
68
69                   1
70                   |
71                   2
72                  / \
73                 3   4
74                    / \
75       +---------->5   6
76       |          / \ /
77       |    +--->8   7
78       |    |   /    |
79       |    +--9    11
80       |      /      |
81       +--- 10 ---> 12
82
83
84  We have a dominator tree which looks like
85
86                   1
87                   |
88                   2
89                  / \
90                 /   \
91                3     4
92                   / / \ \
93                   | | | |
94                   5 6 7 12
95                   |   |
96                   8   11
97                   |
98                   9
99                   |
100                  10
101
102
103
104  The dominator tree is the basis for a number of analysis, transformation
105  and optimization algorithms that operate on a semi-global basis.
106
107  The dominator walker is a generic routine which visits blocks in the CFG
108  via a depth first search of the dominator tree.  In the example above
109  the dominator walker might visit blocks in the following order
110  1, 2, 3, 4, 5, 8, 9, 10, 6, 7, 11, 12.
111
112  The dominator walker has a number of callbacks to perform actions
113  during the walk of the dominator tree.  There are two callbacks
114  which walk statements, one before visiting the dominator children,
115  one after visiting the dominator children.  There is a callback
116  before and after each statement walk callback.  In addition, the
117  dominator walker manages allocation/deallocation of data structures
118  which are local to each block visited.
119
120  The dominator walker is meant to provide a generic means to build a pass
121  which can analyze or transform/optimize a function based on walking
122  the dominator tree.  One simply fills in the dominator walker data
123  structure with the appropriate callbacks and calls the walker.
124
125  We currently use the dominator walker to prune the set of variables
126  which might need PHI nodes (which can greatly improve compile-time
127  performance in some cases).
128
129  We also use the dominator walker to rewrite the function into SSA form
130  which reduces code duplication since the rewriting phase is inherently
131  a walk of the dominator tree.
132
133  And (of course), we use the dominator walker to drive our dominator
134  optimizer, which is a semi-global optimizer.
135
136  TODO:
137
138    Walking statements is based on the block statement iterator abstraction,
139    which is currently an abstraction over walking tree statements.  Thus
140    the dominator walker is currently only useful for trees.  */
141
142static int *bb_postorder;
143
144static int
145cmp_bb_postorder (const void *a, const void *b)
146{
147  basic_block bb1 = *(basic_block *)const_cast<void *>(a);
148  basic_block bb2 = *(basic_block *)const_cast<void *>(b);
149  if (bb1->index == bb2->index)
150    return 0;
151  /* Place higher completion number first (pop off lower number first).  */
152  if (bb_postorder[bb1->index] > bb_postorder[bb2->index])
153    return -1;
154  return 1;
155}
156
157/* Recursively walk the dominator tree.
158   BB is the basic block we are currently visiting.  */
159
160void
161dom_walker::walk (basic_block bb)
162{
163  basic_block dest;
164  basic_block *worklist = XNEWVEC (basic_block,
165				   n_basic_blocks_for_fn (cfun) * 2);
166  int sp = 0;
167  int *postorder, postorder_num;
168
169  if (m_dom_direction == CDI_DOMINATORS)
170    {
171      postorder = XNEWVEC (int, n_basic_blocks_for_fn (cfun));
172      postorder_num = inverted_post_order_compute (postorder);
173      bb_postorder = XNEWVEC (int, last_basic_block_for_fn (cfun));
174      for (int i = 0; i < postorder_num; ++i)
175	bb_postorder[postorder[i]] = i;
176      free (postorder);
177    }
178
179  while (true)
180    {
181      /* Don't worry about unreachable blocks.  */
182      if (EDGE_COUNT (bb->preds) > 0
183	  || bb == ENTRY_BLOCK_PTR_FOR_FN (cfun)
184	  || bb == EXIT_BLOCK_PTR_FOR_FN (cfun))
185	{
186	  /* Callback for subclasses to do custom things before we have walked
187	     the dominator children, but before we walk statements.  */
188	  before_dom_children (bb);
189
190	  /* Mark the current BB to be popped out of the recursion stack
191	     once children are processed.  */
192	  worklist[sp++] = bb;
193	  worklist[sp++] = NULL;
194
195	  int saved_sp = sp;
196	  for (dest = first_dom_son (m_dom_direction, bb);
197	       dest; dest = next_dom_son (m_dom_direction, dest))
198	    worklist[sp++] = dest;
199	  if (m_dom_direction == CDI_DOMINATORS)
200	    switch (sp - saved_sp)
201	      {
202	      case 0:
203	      case 1:
204		break;
205	      default:
206		qsort (&worklist[saved_sp], sp - saved_sp,
207		       sizeof (basic_block), cmp_bb_postorder);
208	      }
209	}
210      /* NULL is used to mark pop operations in the recursion stack.  */
211      while (sp > 0 && !worklist[sp - 1])
212	{
213	  --sp;
214	  bb = worklist[--sp];
215
216	  /* Callback allowing subclasses to do custom things after we have
217	     walked dominator children, but before we walk statements.  */
218	  after_dom_children (bb);
219	}
220      if (sp)
221	bb = worklist[--sp];
222      else
223	break;
224    }
225  if (m_dom_direction == CDI_DOMINATORS)
226    {
227      free (bb_postorder);
228      bb_postorder = NULL;
229    }
230  free (worklist);
231}
232