1 /* Generic dominator tree walker 2 Copyright (C) 2003-2015 Free Software Foundation, Inc. 3 Contributed by Diego Novillo <dnovillo@redhat.com> 4 5 This file is part of GCC. 6 7 GCC is free software; you can redistribute it and/or modify 8 it under the terms of the GNU General Public License as published by 9 the Free Software Foundation; either version 3, or (at your option) 10 any later version. 11 12 GCC is distributed in the hope that it will be useful, 13 but WITHOUT ANY WARRANTY; without even the implied warranty of 14 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 15 GNU General Public License for more details. 16 17 You should have received a copy of the GNU General Public License 18 along 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 142 static int *bb_postorder; 143 144 static int 145 cmp_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 160 void 161 dom_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