gcc/domwalk.c

   1 /* Generic dominator tree walker
   2    Copyright (C) 2003-2014 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 }