Live "variable" analysis

Live "variable" analysis

1. The last step in this process is to actually assign temporaries to the groups of related instances found using the results of the "reaching definitions" analysis.
2. The standard approach to this problem is based on graph-coloring:
   • We build a graph with one node for each set of instances that must be assigned a temporary locations. This graph is called the interference graph.
   • We connect two nodes with an edge if at some point in the program the values of at least one instance occurring in each of the sets of CSE instances associated with the nodes may be needed in the future to avoid computing the value of a redundant CSE.
   • We then assign colors (actually temporary location names) to the nodes in such a way that no two connected nodes have the same color.
3. Coloring a graph is an NP-complete problem, but this doesn't seem to bother anyone. Using simple, greedy heuristics apparently works well in progress.
4. The issue I want you to think about, is how to we determine which nodes in the graph to connect. That is, how to we decide if the value produced by an instance of an expression may be used in the future.
5. Once again, we can answer the problem using the data-flow analysis approach.
6. Recall from the discussion of Reaching definitions that once we have solved the Available expressions problem we can identify instances of CSE's as uses and definitions.
7. To figure out what values must be kept in temporaries at a particular point we will solve a problem that might be called "reachable uses" (but is actually called "live variables"). Basically, for each program point we will determine the set of CSE instances that are a) uses and b) reachable from the program point through an execution path that does not include any other definition of the expression.
8. Once again, it helps to have some auxiliary functions:

   use(exp)

   will be the set of redundant CSE instances occurring as sub-expressions of exp

   kill(exp)

   will be the set of all redundant CSE instances that are textually equivalent to any non-redundant CSE instance appearing as a sub-expression of exp

9. Then, the equations for determining which instances are "LIVE" at a particular point are:

   assignment statements

   Given an assignment of the form

   < p₁ > x := exp < p₂ >

   LIVE(p₁) = LIVE(p₂) + use(exp) - kill(exp)

   if statement

   Given an if statement of the form:

   < p0 >	if exp	then	< p1 > stmt1 < p3 >
   		else	< p2 > stmt2 < p4 >
   	end < p5 >

   It must be the case that:

   LIVE( p₀ ) = LIVE( p₁ ) + LIVE( p₂ ) + use(exp)

   LIVE( p₃ ) = LIVE( p₄ ) = LIVE( p₅ )

   while loop

   Given a while loop of the form:

   < p0 >	while	exp do
   		< p1 > stmt < p2 >
   	end < p3 >

   it must be the case that:

   LIVE( p₀ ) = LIVE( p₁ ) + LIVE( p₃ ) + use( exp )

   LIVE( p₂ ) = LIVE( p₀ )

10. The values needed by two expression instances that are live at a given program point must not be assigned to the same temporaries (unless the instances are instances of the same CSE).

    So, the "liveness" information gives you what is needed to build an interference graph and do temporary (i.e. register) allocation.

11. All the data-flow problems used to do redundant CSE elimination obviously have a lot in common. There are some important differences:
    • Two of the problems (available expressions and reaching definitions) involved the flow of information in the same direction as program execution would flow. These are called "forward" analysis problems. The Live variable problem, on the other hand, is a "backward" analysis problem.
    • Two of the problems collected information about what "may" happen during execution (live variables and reaching definitions) while one (available expressions) involved things that "must" happen.

    These categories are used to partition data-flow analysis problems into four groups (of which you have seen everything but a backwards-must example).

Live "variable" analysis