#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "backend.h"
#include "cfganal.h"
#include "domwalk.h"
#include "dumpfile.h"

Include dependency graph for domwalk.cc:

Functions
static int	cmp_bb_postorder (const void a, const void b, void *data)

static void	sort_bbs_postorder (basic_block bbs, int n, int bb_postorder)

void	set_all_edges_as_executable (function *fn)

Function Documentation

◆ cmp_bb_postorder()

static int cmp_bb_postorder	(	const void *	a,
		const void *	b,
		void *	data )

static

Generic dominator tree walker
   Copyright (C) 2003-2024 Free Software Foundation, Inc.
   Contributed by Diego Novillo <dnovillo@redhat.com>

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3.  If not see
<http://www.gnu.org/licenses/>.

This file implements a generic walker for dominator trees.

To understand the dominator walker one must first have a grasp of dominators,
immediate dominators and the dominator tree.

Dominators
  A block B1 is said to dominate B2 if every path from the entry to B2 must
  pass through B1.  Given the dominance relationship, we can proceed to
  compute immediate dominators.  Note it is not important whether or not
  our definition allows a block to dominate itself.

Immediate Dominators:
  Every block in the CFG has no more than one immediate dominator.  The
  immediate dominator of block BB must dominate BB and must not dominate
  any other dominator of BB and must not be BB itself.

Dominator tree:
  If we then construct a tree where each node is a basic block and there
  is an edge from each block's immediate dominator to the block itself, then
  we have a dominator tree.


[ Note this walker can also walk the post-dominator tree, which is
  defined in a similar manner.  i.e., block B1 is said to post-dominate
  block B2 if all paths from B2 to the exit block must pass through
  B1.  ]

For example, given the CFG

                 1
                 |
                 2
                / \
               3   4
                  / \
     +---------->5   6
     |          / \ /
     |    +--->8   7
     |    |   /    |
     |    +--9    11
     |      /      |
     +--- 10 ---> 12


We have a dominator tree which looks like

                 1
                 |
                 2
                / \
               /   \
              3     4
                 / / \ \
                 | | | |
                 5 6 7 12
                 |   |
                 8   11
                 |
                 9
                 |
                10



The dominator tree is the basis for a number of analysis, transformation
and optimization algorithms that operate on a semi-global basis.

The dominator walker is a generic routine which visits blocks in the CFG
via a depth first search of the dominator tree.  In the example above
the dominator walker might visit blocks in the following order
1, 2, 3, 4, 5, 8, 9, 10, 6, 7, 11, 12.

The dominator walker has a number of callbacks to perform actions
during the walk of the dominator tree.  There are two callbacks
which walk statements, one before visiting the dominator children,
one after visiting the dominator children.  There is a callback
before and after each statement walk callback.  In addition, the
dominator walker manages allocation/deallocation of data structures
which are local to each block visited.

The dominator walker is meant to provide a generic means to build a pass
which can analyze or transform/optimize a function based on walking
the dominator tree.  One simply fills in the dominator walker data
structure with the appropriate callbacks and calls the walker.

We currently use the dominator walker to prune the set of variables
which might need PHI nodes (which can greatly improve compile-time
performance in some cases).

We also use the dominator walker to rewrite the function into SSA form
which reduces code duplication since the rewriting phase is inherently
a walk of the dominator tree.

And (of course), we use the dominator walker to drive our dominator
optimizer, which is a semi-global optimizer.

TODO:

  Walking statements is based on the block statement iterator abstraction,
  which is currently an abstraction over walking tree statements.  Thus
  the dominator walker is currently only useful for trees.

References a, b, bb_postorder, and basic_block_def::index.

Referenced by sort_bbs_postorder().

◆ set_all_edges_as_executable()

void set_all_edges_as_executable ( function * fn )

Set EDGE_EXECUTABLE on every edge within FN's CFG.

References FOR_ALL_BB_FN, FOR_EACH_EDGE, and basic_block_def::succs.

Referenced by execute_early_warn_uninitialized(), execute_fast_vrp(), execute_ranger_vrp(), and dom_walker::walk().

◆ sort_bbs_postorder()

static void sort_bbs_postorder	(	basic_block *	bbs,
		int	n,
		int *	bb_postorder )

static

Permute array BBS of N basic blocks in postorder,
i.e. by descending number in BB_POSTORDER array.

References bb_postorder, cmp_bb_postorder(), gcc_sort_r(), basic_block_def::index, and LIKELY.

Referenced by dom_walker::walk().

Functions

Function Documentation

◆ cmp_bb_postorder()

◆ set_all_edges_as_executable()

◆ sort_bbs_postorder()