Control-flow graph

In computer science, a control-flow graph (CFG) is a representation, using graph notation, of all paths that might be traversed through a program during its execution. The control-flow graph was discovered by Frances E. Allen,^[1] who noted that Reese T. Prosser used boolean connectivity matrices for flow analysis before.^[2]

The CFG is essential to many compiler optimizations and static-analysis tools.

YouTube Encyclopedic

1/5
Views:
119 826
112 051
10 378
55 857
1 030

Transcription

Let's look at the code for PrintSum in a slightly different way by making something explicit. If we go through the code, we can see that the, the code does something in that case, if the result greater then zero, does something else if the result is not greater than zero but is less than zero, and otherwise in the case in which neither of these two conditions is true. Nothing really happens. So we're going to make that explicit, we're going to say here, otherwise do nothing, which is exactly our problem, the code does nothing, in this case where it should do something. So now, let's look again in our test cases, let's consider the first one, and I'm going to go a little faster in this case, because we already saw what happens If we execute the first test case, we get to this point, we execute this statement, and then we just jump to the end, as we saw. Now we, if we execute the second test case, we do the same, we get to the else statement, the condition for the if is true, and therefore we execute this statement. And we never reached this point for either of the test cases. So how can we express this? In order to do that, I'm going to introduce a very useful concept. The concept of control flow graphs. The control flow graphs is just a representation for the code that is very convenient when we run our reason about the code and its structure. And it's a fairly simple one that represents statement with notes and the flow of control within the code with edges. So here's an example of control flow graph for this code. There is the entry point of the code right here, then our statement in which we assign the result of A plus B to variable result. Our if statement and as you can see the if statement it's got two branches coming out of it, because based on the outcome of this predicate we will go one way or the other. In fact normally what we do, we will label this edges accordingly. So for example, here we will say that this is the label to be executed when the predicate is true. And this is the label that is executed when the predicate is false. Now, at this point, similar thing, statement five which corresponds with this one, we have another if statement and if that statement is true, then we get to this point and if it's false, we get to this point. So as you can see, this graph represents my code, in a much more intuitive way, because I can see right away where the control flows, while I execute the code. So we're going to use this representation to introduce further coverage criteria.

Definition

In a control-flow graph each node in the graph represents a basic block, i.e. a straight-line piece of code without any jumps or jump targets; jump targets start a block, and jumps end a block. Directed edges are used to represent jumps in the control flow. There are, in most presentations, two specially designated blocks: the entry block, through which control enters into the flow graph, and the exit block, through which all control flow leaves.^[3]

Because of its construction procedure, in a CFG, every edge A→B has the property that:

outdegree(A) > 1 or indegree(B) > 1 (or both).^[4]

The CFG can thus be obtained, at least conceptually, by starting from the program's (full) flow graph—i.e. the graph in which every node represents an individual instruction—and performing an edge contraction for every edge that falsifies the predicate above, i.e. contracting every edge whose source has a single exit and whose destination has a single entry. This contraction-based algorithm is of no practical importance, except as a visualization aid for understanding the CFG construction, because the CFG can be more efficiently constructed directly from the program by scanning it for basic blocks.^[4]

Example

Consider the following fragment of code:

0: (A) t0 = read_num
1: (A) if t0 mod 2 == 0
2: (B)     print t0 + " is even."
3: (B)     goto 5
4: (C) print t0 + " is odd."
5: (D) end program

In the above, we have 4 basic blocks: A from 0 to 1, B from 2 to 3, C at 4 and D at 5. In particular, in this case, A is the "entry block", D the "exit block" and lines 4 and 5 are jump targets. A graph for this fragment has edges from A to B, A to C, B to D and C to D.

Reachability

Reachability is a graph property useful in optimization.

If a subgraph is not connected from the subgraph containing the entry block, that subgraph is unreachable during any execution, and so is unreachable code; under normal conditions it can be safely removed.

If the exit block is unreachable from the entry block, an infinite loop may exist. Not all infinite loops are detectable, see Halting problem. A halting order may also exist there.

Unreachable code and infinite loops are possible even if the programmer does not explicitly code them: optimizations like constant propagation and constant folding followed by jump threading can collapse multiple basic blocks into one, cause edges to be removed from a CFG, etc., thus possibly disconnecting parts of the graph.

Domination relationship

A block M dominates a block N if every path from the entry that reaches block N has to pass through block M. The entry block dominates all blocks.

In the reverse direction, block M postdominates block N if every path from N to the exit has to pass through block M. The exit block postdominates all blocks.

It is said that a block M immediately dominates block N if M dominates N, and there is no intervening block P such that M dominates P and P dominates N. In other words, M is the last dominator on all paths from entry to N. Each block has a unique immediate dominator.

Similarly, there is a notion of immediate postdominator, analogous to immediate dominator.

The dominator tree is an ancillary data structure depicting the dominator relationships. There is an arc from Block M to Block N if M is an immediate dominator of N. This graph is a tree, since each block has a unique immediate dominator. This tree is rooted at the entry block. The dominator tree can be calculated efficiently using Lengauer–Tarjan's algorithm.

A postdominator tree is analogous to the dominator tree. This tree is rooted at the exit block.

Special edges

A back edge is an edge that points to a block that has already been met during a depth-first (DFS) traversal of the graph. Back edges are typical of loops.

A critical edge is an edge which is neither the only edge leaving its source block, nor the only edge entering its destination block. These edges must be split: a new block must be created in the middle of the edge, in order to insert computations on the edge without affecting any other edges.

An abnormal edge is an edge whose destination is unknown. Exception handling constructs can produce them. These edges tend to inhibit optimization.

An impossible edge (also known as a fake edge) is an edge which has been added to the graph solely to preserve the property that the exit block postdominates all blocks. It cannot ever be traversed.

Loop management

A loop header (sometimes called the entry point of the loop) is a dominator that is the target of a loop-forming back edge. The loop header dominates all blocks in the loop body. A block may be a loop header for more than one loop. A loop may have multiple entry points, in which case it has no "loop header".

Suppose block M is a dominator with several incoming edges, some of them being back edges (so M is a loop header). It is advantageous to several optimization passes to break M up into two blocks M_pre and M_loop. The contents of M and back edges are moved to M_loop, the rest of the edges are moved to point into M_pre, and a new edge from M_pre to M_loop is inserted (so that M_pre is the immediate dominator of M_loop). In the beginning, M_pre would be empty, but passes like loop-invariant code motion could populate it. M_pre is called the loop pre-header, and M_loop would be the loop header.

Reducibility

A reducible CFG is one with edges that can be partitioned into two disjoint sets: forward edges, and back edges, such that:^[5]

Forward edges form a directed acyclic graph with all nodes reachable from the entry node.
For all back edges (A, B), node B dominates node A.

Structured programming languages are often designed such that all CFGs they produce are reducible, and common structured programming statements such as IF, FOR, WHILE, BREAK, and CONTINUE produce reducible graphs. To produce irreducible graphs, statements such as GOTO are needed. Irreducible graphs may also be produced by some compiler optimizations.

Loop connectedness

The loop connectedness of a CFG is defined with respect to a given depth-first search tree (DFST) of the CFG. This DFST should be rooted at the start node and cover every node of the CFG.

Edges in the CFG which run from a node to one of its DFST ancestors (including itself) are called back edges.

The loop connectedness is the largest number of back edges found in any cycle-free path of the CFG. In a reducible CFG, the loop connectedness is independent of the DFST chosen.^[6]^[7]

Loop connectedness has been used to reason about the time complexity of data-flow analysis.^[6]

Inter-procedural control-flow graph

While control-flow graphs represent the control flow of a single procedure, inter-procedural control-flow graphs represent the control flow of whole programs.^[8]

References

^ Frances E. Allen (July 1970). "Control flow analysis". SIGPLAN Notices. 5 (7): 1–19. doi:10.1145/390013.808479.
^ Reese T. Prosser (1959). "Applications of Boolean matrices to the analysis of flow diagrams". Papers presented at the December 1–3, 1959, eastern joint IRE-AIEE-ACM computer conference. pp. 133–138. doi:10.1145/1460299.1460314.
^ Yousefi, Javad (2015). "Masking wrong-successor Control Flow Errors employing data redundancy". 2015 5th International Conference on Computer and Knowledge Engineering (ICCKE). IEEE. pp. 201–205. doi:10.1109/ICCKE.2015.7365827. ISBN 978-1-4673-9280-8.
^ ^a ^b Peri L. Tarr; Alexander L. Wolf (2011). Engineering of Software: The Continuing Contributions of Leon J. Osterweil. Springer Science & Business Media. p. 58. ISBN 978-3-642-19823-6.
^ "Archived copy" (PDF). Archived from the original (PDF) on 2020-08-01. Retrieved 2018-03-24.{{cite web}}: CS1 maint: archived copy as title (link)
^ ^a ^b Kam, John B.; Ullman, Jeffrey D. (1976-01-01). "Global Data Flow Analysis and Iterative Algorithms". Journal of the ACM. 23 (1): 158–171. doi:10.1145/321921.321938. ISSN 0004-5411. S2CID 162375.
^ Offner, Carl. "Notes on Graph Algorithms Used in Optimizing Compilers" (PDF). Archived (PDF) from the original on 2008-07-25. Retrieved 13 April 2018.
^ "Control Flow Analysis" (PDF). 2016. Archived (PDF) from the original on 2016-12-19.

External links

Wikimedia Commons has media related to Control flow graph.

Examples

Avrora – Control-Flow Graph Tool Archived 2011-08-25 at the Wayback Machine

This page was last edited on 14 March 2024, at 04:24

From Wikipedia, the free encyclopedia