Interprocedural Analysis: Computing Summary Information

Introduction

• 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: Add a new exit node and an edge n → exit for each node n with no outgoing edges, and for one node n of every strongly connected component (note that sccs are not collapsed).

Step 4: Put dataflow functions on the edges of the call graph. The function on all edges to the exit node is the identity function. For other edges, the function filters out the locals of the called function, and "backbinds" the formals of the called functions to the actuals of the calling procedure. Here is the example call graph with the added exit node and the dataflow functions:

Step 5: Determine GREF sets for each node n and each call site s (corresponding to call graph edge m→n with dataflow function f_s) as the greatest fixed point of the following set of equations:

GREF(exit) = { }
GREF(n) = (union of all GREF(s) such that s is a call site in n) U IREF(n)
GREF(s) = fs(GREF(n))

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)    = { }             ---                              { }

Note also that for dataflow analysis, it is the call site GMOD sets that we would use to define the dataflow function for a call node, not the called procedure's GMOD set (because the GMOD set for the call site tells what may be modified as a result of that particular call, rather than what might be modified by the called procedure on some call).