Interprocedural Analysis

Motivation

    x=0;  
	// is y live here? (yes iff used in procedure P)
    call P();
	// is x still equal to 0 here? (yes iff not changed in P)
    y=x;

We also need information about call sites to start dataflow analysis for procedures other than "main". For example:

    procedure P(int a, int b)
    { // what are the values of a, b, and globals here?
      .
      .
      .
      // what globals are live here?
      // if a and b are passed by reference, are they live here?
     }

Note that pointers and reference parameters make it especially difficult to answer these kinds of questions. For example:

procedure P(ref x, ref y) {
    x = 0;
    y = 1;
            // is x==0 here? yes iff x,y not aliases
    g = 0;
            // is y==1 here? yes iff y,g not aliases
    *p = 1;
            // is g==0 here? yes iff p does not point to g
}

There are several possible approaches to handling programs with procedure calls; some address what to do for procedure entry/exit; some address what to do for a procedure call; some address both issues. We will look at the following approaches:

• Use safe dataflow functions
• Use the supergraph
• Use summary information (GMOD and GREF)
• Use summary functions

For example:

1. Dataflow functions for entry/exit nodes:

• Reaching Defs: the function for the enter node returns the set (x, enter) for all globals and formal parameters x (i.e., we consider there to be an implicit assignment to all globals and formals at the entry node).
• Constant Propagation: the function for the enter node returns the empty set (i.e., no variables are considered to be constant at the start of the procedure).
• Live Variables: the function for the exit node returns the set of all global variables (i.e., all globals are considered to be live after this procedure returns).

2. Dataflow functions for call node n:

• Reaching Defs: f_n(S) = S U {(g,n) | g is a global}; i.e., we consider every call to be a potential definition of every global (note that since the call may not define a global, the dataflow function does not remove anything from the reaching-definitions set).
• Constant Propagation: f_n(S) = S - (g, *), where g is a global (i.e., we consider every procedure call as setting every global to a non-constant value).
• Live Variables: f_n(S) = S U {x | x is a global or an actual in this call}; i.e., we consider every global live before every call, and we assume that every actual may be used in the called procedure before being overwritten.

Approach 2 (use the supergraph)

• for each node "call P", add an edge from that node to "enter P"
• for each node "exit P", add an edge from that node to all nodes following a "call P" node.

A problem with this approach is that it includes interprocedurally invalid paths: paths that correspond to a procedure being called from one call site but returning to another. This is bad because the results of the analysis will generally be less accurate (i.e., more conservative) than if the paths were restricted to include only interprocedurally valid paths (paths that go from a call site to the called procedure and back to the same call site). For example, the following shows a supergraph with an invalid path shown using purple edges (representing the first call to P returning to the second call site).

Approach 3 (use summary information)

Example

Assume we know that procedure P may modify globals x and y, and may use globals y and z. Below are the dataflow functions we would use for node n, a call to P, for several dataflow problems.

Dataflow Problem	Dataflow Function for Call Node n
reaching definitions	fn(S) = S U {(x,n),(y,n)}
live variables	fn(S) = S U {y,z}
constant propagation	fn(S) = S - ((x, *), (y, *))

Notes:

1. For reaching definitions, we cannot assume that the procedure call kills anything (because all we know is that procedure P may modify x and y). Similarly, for live variables, we cannot assume that the call "kills" any variables.
2. If we know that P might use its first formal parameter, and the call at node n is: P(a, b), then the dataflow function for live variables must also add "a" to the given set.

The summary information that we want to compute for each procedure P is:

• GMOD(P) = the set of variables that might be modified as a result of calling P (directly or transitively)
• GREF(P) = the set of variables that might be used as a result of calling P (directly or transitively)

Initially, we will assume that the program we're analyzing has:

• no pointers (including pointers to procedures)
• no parameters

Step 1: Compute IMOD and IREF

These sets are similar to GMOD and GREF, but they include only variables that are directly used or modified. This can be done in one pass through the procedure's CFG (ignoring control flow). Just look for assignments and uses of globals.

Step 2: Build the call graph

• one node for each procedure
• edge f→g iff f calls g (only one edge even if f calls g more than once)

Step 3: Collapse cycles.

Note that all nodes in a strongly connected component (scc) of the call graph will have the same GMOD/GREF sets. So we can collapse each scc into a single node, setting its IMOD/IREF set to the union of the sets of the nodes of the scc. For example, here is a call graph with the IMOD sets for each procedure:
In this example, the nodes for procedures c and d form a strongly connected component, so those two nodes can be collapsed into a single node with IMOD = {g3, g4}.

Step 4: Compute GMOD and GREF.

We can compute GMOD and GREF sets for each procedure (each node of the graph) using a backward dataflow analysis on the simplified call graph as follows:
• Add a new exit node (and add an edge n → exit for each node n with no outgoing edge.
• A lattice element is a set of (global) variables.
• The lattice meet is set union.
• The "initial" dataflow fact for both GMOD and GREF (the fact that holds at the exit node) is the empty set.
• for all nodes n, the dataflow functions for n are:
  GMOD: f_n(S) = S U IMOD(n)
  GREF: f_n(S) = S U IREF(n)
• Note that since the simplified call graph is acyclic, we can solve this dataflow problem in one pass, using reverse topological order.

Now let's relax our initial assumption that there are no parameters, and consider procedures with value parameters. In this case, the computation of GMOD sets will not change, but the computation of GREF sets must change. (We want to consider a call like p( x ) a use of x iff p might use the corresponding formal, so we need to take formal parameters into account when computing GREF sets).

Step 1: Compute IREF sets as before, but include local variables and formal parameters.

Step 2: Build the call graph, but this time include one edge for every call site (so there can be multiple edges between pairs of nodes). For example, here's a program:

void main() {         void a( f1 ) {           void b( f2, f3 ) {
s1: call a(v1);	      s2: call b(v2, v3);          print f3;
}                     s3: call b(v4, v5);      s4: call b( g1, g2 );
                                               }

Step 3: Compute GREF sets for each node n and for each callsite s as the greatest fixed point of the following set of equations:

GREF(n) = (union of all GREF(s) such that s is a call site in n) U IREF(n)
GREF(s) = GREF(called node m) with all formals mapped back to the corresponding actuals

For the running example, the final values are:

node or call site	GREF set
main	g2
a	g2, v3, v5
b	f3, g2
s1	g2
s2	v3, g2
s3	v5, g2
s4	g2

Finally, let's think about what happens when we allow reference parameters. In a sense, this introduces two problems:

1. The IMOD/IREF sets are not complete because of aliases:

   void a( f1, f2 ) {
       f1 = f2 + 1;
   }
          

   In this example, f1 and all of its aliases are modified; f2 and all of its aliases are used. The aliases can include globals (due to a call like: a( g1, g2 )) or other formals (due to a call like: a( x, x )).

   Similarly, any def/use of a global is actually a def/use of the formals to which it is aliased, too.

2. Since a procedure's IMOD/IREF sets are not complete, neither are its GMOD/GREF sets, which means that incomplete information is propagated to its callers. For example, here is a call graph in which each node represents one procedure, the code for that procedure is given in the node, and the IMOD and GMOD sets that would be computed using a straightforward extension of the algorithm used above for value parameters, are shown to the right:

   +-------------+
   | void main() |  IMOD = { }
   | call a( g ) |  GMOD = { g }
   +-------------+
         |
         v
   +--------------+
   | void a( f1 ) |  IMOD = { }
   | call b( f1 ) |  GMOD = { f1 }
   +--------------+
         |
         v
   +--------------+
   | void b( f2 ) |
   | f2 = 0       |  GMOD = IMOD = { f2 }
   +--------------+
   

   Note that in b, f2 is aliased to g, so b actually modifies g as well as f2; this is an example of problem 1, discussed above. However, since b does modify g (due to the call from a), it is also true that a modifies g. Yet g is not in GMOD(a). This is the example of problem 2.

1. Compute DMOD/DREF: modify/use sets that ignore the effects of aliasing due to reference parameters (essentially the GMOD/GREF sets computed by the algorithm discussed above for value parameters).

2. Compute alias sets for all formal parameters and all globals on a per-procedure basis:
   • Alias(f,p) = {x | x is a formal of p or a global, and is aliased to f}
   • Alias(g, p) = {x | x is a formal of p and is aliased to g}
3. Combine the results of (1) and (2) to determine:
   • What each call may actually define/use (transitively)
   • What each def/use of a formal f or a global g may actually define/use.

Computing DMOD and DREF

The computation of DMOD/DREF is similar to the method for computing GMOD/GREF given only value parameters; i.e., dataflow functions go on the edges of the call (multi)graph, and IMOD/IREF sets are propagated back across those edges, replacing formals with actuals. Here is an example; the values shown on the edges are the actuals of the calls that are modified by the called procedure (i.e., the corresponding formals are in the called procedures' IMOD or DMOD sets):

s1:   { x }
s2:   { g2 }
s3:   { g3 }
s4:   { f2 }
s5:   { }
main: { x, g2, g3 }
a:    { f2 }
b:    { f3 }
c:    { }

The next step is to compute the alias sets. This has been described in the paper "Fast Interprocedural Alias Analysis" by Keith Cooper and Ken Kennedy, published in the Conference Record of the Sixteenth Annual ACM Symposium on Principles of Programming Languages (1989).

Alias sets can be computed in two steps:

1. Use the "binding graph" to compute formal/global aliases.
2. Use the "pair binding graph" to compute formal/formal aliases.

The binding graph for a program includes a node for each formal of each procedure, and an edge f1 → f2 iff f1 is passed as an actual parameter in some call to p, and f2 is the corresponding formal of p. For example, at call site s4 in procedure a of the program shown above, f2 is the 1st actual, and f3 is the corresponding formal of the called procedure b. Therefore, in the program's binding graph there would be an edge f2 → f3. Here is the complete binding graph for the example program:

f1      f2       f4
|       | \
|       |  \
v       v   v
f5      f3  f6

To compute the formal/global aliases (for each formal f, which globals it may be aliased to):

// collapse scc's of binding graph
   replace each scc with a representative node n

// initialize
   for each node x, set A(x) = {}
   for each call site s
      for each global v passed to formal f at s
         A(f) = A(f) U { v }  // if f was in an scc, use the rep. node n for f

// traverse the graph, propagating aliases
   for each node f in topological order
      A(f) = A(f) U A(g) such that g is a predecessor of f

// set values for all nodes of scc's
   for each scc c
      for each node f in c
         let n be c's representative node in
	    A(f) = A(n)

A(f1) = { g1 }
A(f2) = { g2 }
A(f3) = { g3 }
A(f4) = { g1 }
A(f5) = { }
A(f6) = { }

The propagation loop would add g2 to the sets of f3 and f6, and would add g1 to the set of f5.

Note that this algorithm maps formals to the globals to which they are aliased (f1 → {g1}, etc.). We also want the sets "Alias(g,p) = the set of p's formals to which g is aliased in p". We can get those sets using this algorithm:

for each procedure p
   for each global g
      set Alias(g,p) = { }
   for each formal f of p
      for each g in A(f)
         add f to Alias(g,p)

Alias(g1, a) = { f1 }    Alias(g1, b) = { f4 }    Alias(g1, c) = { f5 }
Alias(g2, a) = { f2 }    Alias(g2, b) = { f3 }    Alias(g2, c) = { f6 }
Alias(g3, a) = { }       Alias(g3, b) = { f3 }    Alias(g3, c) = { }

Now we need to compute the formal/formal aliases. This is done using the "pair binding graph".

There are 3 different ways two formals can be aliased:

1. The same actual is passed to two formals:

   +----------------+
   | call a( x, x ) |
   +----------------+
           |
   	v
   +-------------------+
   | enter a( f1, f2 ) |           f1 and f2 are aliased in a
   +-------------------+
   

2. Global g is passed to one formal, an alias of g to another:

   +-------------+
   | call a( g ) |
   +-------------+
           |
   	v
   +-----------------+
   | enter a( f1 )   |
   | call b( f1, g ) |
   +-----------------+
           |
   	v
   +-------------------+
   | enter b( f2, f3 ) |           f2 and f3 are aliased in b
   +-------------------+
   

3. Formals f1 and f2 are aliases, and are both passed as actuals.

          ...
           |
   	v
   +---------------------+
   | enter a( f1, f2 )   |
   | call b( x, f1, f2 ) |
   +---------------------+
           |
   	v
   +-----------------------+
   | enter b( f3, f4, f5 ) |       f4 and f5 are aliased in b
   +-----------------------+
   

• find where formals become aliased
• propagate alias pairs across calls

Here is the pair binding graph for our example program:

(f1, f2)    (f3, f4)
   |
   |
   v
(f5, f6)

for each call site s
   if var x is passed to two formals f1 and f2
   then {
         // same actual passed twice:
         //       call p(x, x)
         //              |  |
         //              v  v
         //       void p(f1,f2)
      mark (f1,f2)
   }
   for each actual f that is a formal of the procedure containing s
       let f' be the corresponding formal of the called procedure in
	  for each global g in A(f) that is passed as an actual at s
	      // global and its alias passed
	      //     call p(f, g)
	      //            |  |
	      //            v  v
              //     void p(f',f'')
	         let f'' be the corresponding formal in the called procedure in
		     mark (f', f'')
                             

The next step is to propagate the initial alias pairs by marking all nodes reachable from a marked node. This can be done as follows:

put all marked nodes (initial alias pairs) on a worklist
while the worklist is not empty
   remove pair p from the worklist
   for each edge p → q in the pair binding graph
      if q is not marked
      then {
         mark q
	 put q on the worklist
      }

Note that if, in the end, a pair (fj, fk) is marked, it means that fj and fk may be aliased.

The final step in computing formal's aliases is to combine the results computed using the binding graph (which globals each formal is aliased to) with the new results computed using the pair binding graph (which other formals each formal is aliased to):

for each procedure p
   for each formal f of p
      Alias(f, p) = A(f) U {f' | (f, f') or (f', f) is marked in the pair binding graph}

Alias(f1, a) = { g1, f2 }    Alias(f1, b) = { }           Alias(f1, c) = { }
Alias(f2, a) = { g2, f1 }    Alias(f2, b) = { }           Alias(f2, c) = { }
Alias(f3, a) = { }           Alias(f3, b) = { g2, g3 }    Alias(f3, c) = { }
Alias(f4, a) = { }           Alias(f4, b) = { g1 }        Alias(f4, c) = { }
Alias(f5, a) = { }           Alias(f5, b) = {  }          Alias(f5, c) = { g1, f6 }
Alias(f6, a) = { }           Alias(f6, b) = {  }          Alias(f6, c) = { g2, f5 }
Alias(g1, a) = { f1 }        Alias(g1, b) = { f4 }        Alias(g1, c) = { f5 }
Alias(g2, a) = { f2 }        Alias(g2, b) = { f3 }        Alias(g2, c) = { f6 }
Alias(g3, a) = {  }          Alias(g3, b) = { f3 }        Alias(g3, c) = { }

Once alias information is known, we can use it to compute GMOD sets for every call site and for every procedure:

for each call site s (in procedure p) {
   GMOD(s) = DMOD(s)
   for each formal and global x in DMOD(s) {
      add Alias(x, p) to GMOD(s)
   }
}

for each procedure p {
   GMOD(p) = DMOD(p)
   for each formal and global x in DMOD(p) {
      add Alias(x, p) to GMOD(p)
   }
}

           DMOD             Aliases                           Final GMOD

GMOD(s1) = { x }             ---                              { x }
GMOD(s2) = { g2 }            ---                              { g2 }
GMOD(s3) = { g3 }            ---                              { g3 }
GMOD(s4) = { f2 } U Alias(f2, a) = { f2 } U { f1, g2 } =      { f1, f2, g2 }
GMOD(s5) = { }

GMOD(main) = { x, g2, g3 }   ---                              { x, g2, g3 }
GMOD(a)    = { f2 } U Alias(f2, a) = { f2 } U { f1, g2 } =    { f1, f2, g2 }
GMOD(b)    = { f3 } U Alias(f3, b) = { f3 } U { g2, g3 } =    { f2, f3, g3 }
GMOD(c)    = { }             ---                              { }

The ideas presented here are from a paper called "Two Approaches to Interprocedural Analysis", by Micha Sharir and Amir Pnueli, in a book called Program Flow Analysis, Theory and applications (edited by S. Muchnick and N. Jones).

The paper makes the following assumptions:

• The program has no locals and no parameters, just global variables.
• Each procedure is represented by a CFG, including edges from a call node to the node following the call (i.e., the program is not represented using a supergraph).
• Dataflow functions are associated with CFG edges (the function on the edge n → m reflects the effect of executing n). However, there are no dataflow functions on the edges out of call nodes.

The ideas behind the approach defined by Sharir and Pnueli are as follows; given a program (a set of CFGs) and a (forward) dataflow problem of interest:

• For each procedure p, for each CFG node n, compute the function
  PHI_{enter p, n}
  which summarizes the dataflow effects of all same-level, interprocedurally valid paths in the program from enter p to n; i.e., the PHI functions include the effects of the procedure calls that might be made on a path from the enter node to node n. (A path is valid if call/return edges match; it is same-level if there is no unmatched call or return edge -- if p is recursive then there can be non-same-level valid paths, but we don't want the PHI functions to take those into account).
• Given PHI functions for all nodes, the solution to the dataflow problem can be computed as follows:
  • For the enter node of main, the solution is the special initial fact "init".
  • For all other procedures p, the solution for p's enter node is the meet of the solutions at all nodes that represent calls to p.
  • For all other nodes n in procedure p, the solution is the result of applying n's PHI function to the solution at p's enter node.
• If the dataflow functions are distributive, then the solution is the meet over all interprocedurally valid paths solution.
• If the dataflow functions are monotonic but not distributive, then the solution will be less precise, but still safe, and will not include any facts that arise only from invalid interprocedural paths.

How to use PHI Functions to Solve a Dataflow Problem

As mentioned above, once we have the PHI functions for all CFG nodes, we can solve a (forward) dataflow problem by computing the dataflow fact n.val for each CFG node n as follows:

enter-main.val = "init"
for each procedure p:
                   _                                  _
    enter-p.val = | | c.val            // the symbol | | means "meet"
		  c is a call to p

    n.val = PHIenter p, n (enter-p.val)

Note: If the program is not recursive, then these equations can be solved in one pass using a topological ordering of the call graph. If the program is recursive, then these equations will be recursive, too. In particular, for a recursive procedure p, enter-p.val will depend on a set of values c.val, and at least some of those will depend on enter-p.val. In this case, the greatest fixed point solution can be found using the usual iterative method:

• Start with all values = top, and all nodes on a worklist.
• While the worklist is not empty:
  • remove one node n from the worklist
  • recompute n.val
  • if the new value is different from the old value, then put all nodes that depend on n's value in the worklist

Here is an example program (two CFGs):

          enter main                          enter p
               |                                 |
	       v				 v
	    1: x = 0                           7: if...
	       |                                 |  \
	       v				 |   v
	    2: call p()                          | 8: x = 3
	       |                                 |  /
	       v				 v v
	    3: x = 2                           9: exit
	       |
	       v
	    4: call p()
	       |
	       v
	    5: exit

The PHI functions are defined using the following equations:

1. For all procedures p (including main), the PHI function for the enter node (i.e., PHI_{enter p, enter p}) is the identify function.
2. For all non-enter nodes n in p, the PHI function for node n is the meet over all CFG predecessors m of n of the composition of two functions: h_m,n and PHI_{enter p,m}, where h_m,n is defined to be:

   PHIenter q, exit q	// if m is call q
   fm,n	// otherwise

   where f_m,n is the dataflow function on the CFG edge m→n.

Here is the example program again; each CFG edge is annotated with the dataflow function for reaching-definitions analysis ("id" is used when the function is the identity function):

          enter main                          enter p
               |                                 |
	       | id				 | id
	       v				 v
	    1: x = 0                           7: if...
	       |                                 |  \
	       | f(S)=S-(x,*) U (x,1)	      id |   \ id
	       v				 |    v
	    2: call p()                          | 8: x = 3
	       |                                 |  /
	       |				 | / f(S)=S-(x,*) U (x,8)
	       v				 v v
	    3: x = 2                           9: exit
	       |
	       | f(S)=S-(x,*) U (x,3)
	       v
	    4: call p()
	       |
	       v
	    5: exit

CFG node n	Equation for n's PHI function
1	id o PHIenter main, enter main
2	S-(x,*)U{(x,1)} o PHIenter main, 1
3	PHIenter p, exit p o PHIenter main, 2
4	S-(x,*)U{(x,3)} o PHIenter main, 3
5	PHIenter p, exit p o PHIenter main, 4
7	id o PHIenter p, enter p
8	id o PHIenter p, enter p
9	(id o PHIenter p, 7) meet (S-(x,*)U{(x,8)} o PHIenter p, 8)

We can compute the PHI functions as the greatest solution to this set of equations using the usual iterative approach:

• for each enter node n, set n's PHI function to the id function.
• for each non-enter node n, set n's PHI function to the "top" function (PHI(S) = top, where "top" is the top value in the lattice of dataflow facts).
• put all non-enter nodes into a worklist
• while the worklist is not empty:
  • remove a node n
  • recompute n's PHI function
  • if the new value is different from the old value then put all of n's CFG successors into the worklist; if n is the exit node of function p then for every node m that is a call to p, put all of m's successors into the worklist

In order to compute the PHI functions we need the following properties:

• We can compute the meet of any two functions (needed for equation 2).
• We can compute the composition of any two functions (also needed for equation 2).
• The universe of PHI functions form a lattice with no infinite descending chains (the iterative algorithm initializes the PHI functions to the "top" function and iterates down the lattice -- no infinite descending chains ensures that we eventually reach a fixed point).
• We can compare two PHI functions for equality (so that we can tell whether a node's PHI function has changed).

In order to satisfy the requirement about being able to compare functions for equality, we need a "canonical" representation for the functions, and we need to define the meet and the composition of two functions so that the result is in that canonical form.

One example where this can be done is Gen/Kill dataflow problems, in which the meet is set union. In this case, all dataflow functions are of the form:

f(S) = (S - Kill) U Gen

Here's how we can define f1 meet f2 so that the results are in that same form:

(f1 meet f2)(S) = f1(S) meet f2(S)	// by definition
= f1(S) U f2(S)	// since U is the meet operator
= ((S-K1) U G1) U ((S-K2) U G2)	// expand f1 and f2
= (S-K1) U (S-K2) U G1 U G2	// since union is associative and commutative
= (S - (K1 intersect K2)) U (G1 U G2)	// since (A-B) U (A-C) = A - (B intersect C)

• K = (K1 intersect K2), and
• G = (G1 U G2)

And here's how we can define function composition for Gen/Kill functions so that the result is in canonical form:

(f1 o f2)(S) = f1(f2(S))	// by definition
= f1( (S-K2) U G2 )	// expand f2
= (S-K2 U G2) - K1 U G1	// expand f1
= (S-K2-K1) U (G2-K1) U G1	// because (A U B) - C = (A - C) U (B-C)
= (S-(K2 U K1)) U (G2-K1) U G1	// because (A-B)-C = (A-(B U C))

Putting this all together, let's compute the PHI functions for the example program. Initially, the PHI functions for the two enter nodes would be the identity function. For all other nodes, it would be the top function: f(S) = {} (since the meet for reaching definitions is set union, the top value in the lattice is the empty set; the top function is the constant function that just returns the top value).

All of the non-enter nodes would be on the worklist. Assume that we choose node 1 first. Its equation is:

id o PHI_{enter main, enter main}

S-(x,*) U (x,1) o PHI_{enter main, 1}

S-(x,*) U (x,1)

K1 = (x,*)
K2 = {}
G1 = (x,1)
G2 = {}

(S - (K2 U K1)) U (G2 - K1) U G1	// def of f1 o f2
= (S - ({} U (x,*)) U ({} - (x,*)) U {(x,1)}	// def of K1, K2, G1, G2
= (S - (x,*)) U {(x,1)}

To solve a dataflow problem using PHI functions, perform the following steps:

1. Create a CFG for each procedure, with dataflow functions on the edges.
2. For each CFG node n in procedure p, define the equation for n's PHI function. If n is "enter p", then PHI_{enter p, n} is the id function. Otherwise, PHI_{enter p, n} involves taking the meet of a set of functions, one for each CFG predecessor m of n. Each m contributes one function to the set; that function is itself the composition of two functions: If m is "call q", then the two functions are PHI_{enter q, exit q} and PHI_{enter p, m}. Otherwise, the two functions are f_m→n (the dataflow function on the edge from n to m) and PHI_{enter p, m}.
3. Compute all PHI functions as the greatest solution to the set of equations defined in step 2.
4. Use the PHI functions to solve the dataflow problem: If the program is not recursive, then process the procedures in topological order (on the call graph). To process a procedure p:
   • First set the value of p's enter node.
   • Then, for each node n in p, set n.val = n's PHI function applied to the value of p's enter node.
   Note that, for main, enter-main.val = "init", while for every other procedure p, enter-p.val is the meet of all c.val such that c is "call p" (since we're processing procedures in topological order, when we process procedure p, all nodes "call p" will already have been processed).

   If the program is recursive, then use worklist iteration to set the values of all enter and call nodes, then, for each non-enter, non-call node, compute n.val by applying n's PHI function to its procedure's enter node's value.

Overview