Partial Evaluation

First we will consider how to do partial evaluation of a simple, imperative language. Then we will see what needs to change to handle a simple, functional language.

For now, we will assume that the input to Partial Evaluator PE has three parts:

1. A program P, written in a simple, imperative language with the following features:
   • every basic block starts with a label
   • only the following kinds of statements are allowed:
     • I/O (initial read and final print) statements
     • assignment statements
     • goto <label>
     • if <cond> then goto <label> else goto <label>
   • every basic block ends with a (conditional or unconditional) goto.
   Note that conditional and unconditional gotos can only be at the ends of basic blocks.

   In these notes, we may write code in this low-level language, or we may write the code in a higher-level language (e.g., with loops), with the understanding that PE really works on the low-level form.

2. A division of P's variables (all of its variables, not just its inputs) into static/dynamic, such that for all assignments id = exp, if exp includes any dynamic variables, then id is classified as dynamic. A division that has this property is called a congruent division. (In fact, as we will see later, we really need a stronger property than congruence.)

3. Values for all static inputs.

Example

Below is code that searches two "parallel" name and value lists for a given name that is known to be in the first list. When the name is found (in position j in the name list), it returns the associated value (the value in position j in the value list). Here is a high-level version of the code:

read nameList
read valueList
read name
while (name != car(nameList)) { 
   valueList = cdr(valueList) 
   nameList  = cdr (nameList)  
}                             
print car(valueList)          

          +-------------------------------+
          |  Enter                        |
          +-------------------------------+
                           |
                           v
          +-------------------------------+
          | L1:                           |
          |   read nameList               |
          |   read valueList              |
          |   read name                   |
          |   goto L2                     |
          +-------------------------------+
                           |
                           v
          +-------------------------------+
          | L2:                           |
          |   if (name != car(nameList))  |---------+
          |   then goto L3                |         |
          |   else goto L4                |<--+     |
          +-------------------------------+   |     |
                           |                  |     |
                           v                  |     |
          +-------------------------------+   |     |
          | L3:                           |   |     |
          |   nameList = cdr(nameList)    |   |     |
          |   valueList = cdr(valueList)  |---+     |
          |   goto L2                     |         |
          +-------------------------------+         |
                                                    |
                               +--------------------+
                               |
                               |
                               v
          +-------------------------------+
          | L4:                           |
          |   print car(valueList)        |
          |   goto Exit                   |         
          +-------------------------------+
                               |
                               v
          +-------------------------------+
          |  Exit:                        |
          |    return                     |
          +-------------------------------+

1. the above program, and
2. the division that says that name and nameList are static and valueList is dynamic, and
3. the value ["susan", "john", "ann"] for nameList and "ann" for name

<L1, ("ann", ["susan", "john", "ann"])>: read (valueList)
  valueList = cdr(valueList) valueList = cdr(valueList) print
  car(valueList)

The PE Algorithm

Here's the basic idea of how PE works to produce a residual program:

• Start with pp₀, the first program point, and with vs₀, the initial values of the static variables.
• Process the statements in the current basic block.
• For assignments to static variables, just update vs (and emit no code). For assignments to dynamic variables, simplify the right-hand-side expression as much as possible (using vs), then emit the simplified assignment.
• If the current basic block ends with an unconditional goto, or with a conditional goto whose condition only uses static variables, then do not emit a goto. Instead, append the (residual) code for the block that is the target of the goto to the end of the current (residual) block; i.e., start processing the statements in the target block.
• If the current basic block ends with a conditional goto whose condition uses dynamic variables, then simplify the condition as much as possible and emit it, but change the targets of the gotos to new labels that include the values in vs. Also add the new labels to a worklist of basic block labels that still need to be processed.
• Do the above steps until the worklist is empty.

The PE algorithm is given below. It includes calls to (undefined) function reduce. That function takes an expression and the current values of the static variables, and returns a new version of the expression simplified via constant folding.

PE(program, division, vs0) {
   pending = { (pp0, vs0) }   // pp0 is the label of the first block
   marked = { }

   while (pending is not empty) {
      remove one pair (pp, vs) from pending  // process next basic block
      add (pp, vs) to marked
      emit code label <pp, vs>
      bb = lookup(pp, program)  // bb is a copy of the block labeled pp
      while (bb is not empty) {
         remove the next statement S from bb
         switch (kind(S)) {
          case "read var":
             if (var is dynamic) {
               emit code: read var
             }
             
          case "x = exp":
             if (x is static) {
                update vs with x's new value
             } else {
                emit code: x = reduce(exp, vs)
             }

          case "goto pp'":
             // we're at the end of the current basic block
             // do not emit a goto
             // instead, start processing the code from the target
             // this may cause code duplication (discussed later)
             bb = lookup(pp', program)  

          case "print exp":
             emit code: print reduce(exp, vs)

          case "if exp then goto pp1 else goto pp2":
             // this must be the last stmt in the current basic block
             if (exp is static) {
                // similar to unconditional goto above
                // don't emit a goto
                // instead, start processing the code from the target
                if (reduce(exp, vs)) {
                   bb = lookup(pp1, program)
                } else {
                   bb = lookup(pp2, program)
                }
             } else {
               // exp uses a dynamic variable
               // if we already generated code for pp1 and/or pp2 with
               // current values of static vars, then don't put those
               // labels in "pending" or we might never terminate!
               if ((pp1, vs) not in marked) {
                  insert (pp1, vs) into pending if not already there
               } 
               if ((pp2, vs) not in marked) {
                  insert (pp2, vs) into pending if not already there
               }
               emit code: if reduce(exp) then goto <pp1, vs> else goto <pp2, vs>
             }
         } // end switch
      } // end iterating through current basic block
   } // end while pending set is non-empty
}

Here is a table that traces the execution of the PE algorithm on the example program.

Stmt S	Current bb	vs	Emitted Code
			<L1, ("ann", ["susan", "john", "ann"])>
read nameList	L1	"ann", ["susan", "john", "ann"]
read valueList			read valueList
read name
goto L2
if (name != car(nameList) then goto L3 else goto L4	L2
nameList = cdr(nameList)	L3
valueList = cdr(valueList)		"ann", ["john", "ann"]	valueList = cdr(valueList)
goto L2
if (name != car(nameList) then goto L3 else goto L4	L2
nameList = cdr(nameList)	L3
valueList = cdr(valueList)		"ann", ["ann"]	valueList = cdr(valueList)
goto L2
if (name != car(nameList) then goto L3 else goto L4	L2
print car(valueList)	L4		print car(valueList)

Consider the following code fragment:

  x = 10
  if dynamic-expression then goto L2 else ...

  x = 20
  if dynamic-expression then goto L2 else ...

L2:
  x = 30
  ...

  if dynamic-expression then goto <L2, 10> else ...

  if dynamic-expression then goto <L2, 20> else ...

<L2, 10>:
  x = 30
  ...

<L2, 20>:
  x = 30
  ...

Fortunately, it is not difficult to avoid this problem. If we do standard live-variable analysis, we will know which variables are live at the start of each block. When processing

if dynamic-expression then goto L2 else ...

This binding time analysis produces a congruent division. However, the division is not safe in the sense that it can cause partial evaluation to fail to terminate, even for a program that always terminates. Here's an example:

L1:
  read x
  y = 0
  goto L2

L2:
  if (x > 0) then goto L3 else goto L4

L3:
  y = y + 1
  x = x - 1
  goto L2

L4:
  print y

Given the initial classification x:dynamic, the binding time analysis given above will classify y as static. Let's consider what the PE algorithm will do. It will start by generating the following code:

<L1, ?>:
  read x
  if (x > 0) then goto <L3, 0> else goto <L4, 0>

<L3, 0>:
  x = x - 1
  if (x > 0) then goto <L3, 1> else goto <L4, 1>

Clearly, the algorithm will never terminate, because it keeps generating new instances of the loop for larger and larger values of y.

Jones was aware of this problem, and he investigated alternatives, some of which are discussed in his book. However, we will consider a simpler way to ensure that a division is safe; i.e., if a program terminates, then the PE algorithm will, too. Our approach uses a representation of programs called the Program Dependence Graph, or PDG. It is more straightforward to define PDGs and how to use them to do binding time analysis using a program's high-level form, so that is what we will do below.

The PDG for a procedure has the same nodes as the procedure's control-flow graph (CFG), except that the PDG has no exit node. (We're talking here about a CFG that has one node for each statement and each condition, not one that has one node for each basic block.) The edges of the PDG represent the procedure's flow and control dependences.

Flow-Dependence Edges: Flow-dependence edges are the same as def-use chains: there is a flow-dependence edge m→n iff all of the following hold:

1. m assigns to some variable x
2. n uses x
3. there is an x-definition-free path in the CFG from m to n.

So far, we have assumed that there is just one division that is valid at all program points. This is called a uniform division. The advantages of using a uniform division are that it is simpler to compute and to use than a non-uniform division. However, it has one, potentially major disadvantage: it permits less optimization than a non-uniform division. For example, consider the following program:

read x
read y
z = x + y
y = x * 2
w = z/y
print w

read y
z = 10 + y
y = 20           // why include this assignment?
w = z/y          // why isn't this "w = z/20" ?
print w

An alternative to using a uniform division is to use a pointwise division, which provides one division for each basic block or even for each statement. An unsafe pointwise division can be computed using standard dataflow analysis techniques. The analysis is similar to constant propagation: the dataflow facts at each program point are the variables that are dynamic at that point. The initial dataflow fact is the set of variables specified as dynamic in the initial classification. The dataflow function for an assignment x = exp adds x to the set of dynamic variables if exp includes a dynamic variable, and otherwise it removes x from the set of dynamic variables. However, how to include the effects of control dependences (to make the division safe) is an interesting challenge.

Partial Evaluation of a Simple, Functional Language

Now let's consider how to do partial evaluation of a simple functional language. We'll assume that our language has the following features:

• A program consists of one or more function definitions, one of which must be a definition of main.
• A function definition specifies the function name, the names of its formal parameters, and the expression that is the function body.
• Expressions include the following:
  • identifiers (names of formal parameters)
  • literals:
    • integer values like 1, 2, 3
    • boolean values: true or false
    • strings like "hello"
    • empty lists: nil
    • non-empty, homogeneous lists like [ "a", "b", "c"] or [ 1, 2, 3]
  • if-then-else expressions
  • function calls
  • unary or binary operators, including the usual arithmetic and logical operators, as well as the list operators cons, car, cdr, and nil?.

Here is the example program we used before (the one that searches name and value lists for a given name), this time written in our functional language.

(define (main valueList)
  (call find "ann" ["susan", "john", "ann"] valueList)
)

(define (find name nameList vList)
  (if (= (car nameList) name)
    then (car vList)
    else (call find name (cdr nameList) (cdr vList))
  )
)

As for the procedural case, partial evaluation of a functional program involves two basic steps:

1. Use a binding-time analysis to compute a division that classifies each formal parameter, each function return, and each expression as static or dynamic
2. Specialize the program, using a worklist to keep track of code that still needs to be specialized.

Step 1: Binding Time Analysis

1. The formal parameters and return value of main are dynamic.
2. If any formals of a function are dynamic, then its return value is also dynamic.
3. If the expression used as actual N in a function call is dynamic, then the N^th formal parameter of the called function is also dynamic.

An expression is dynamic if it is any of the following:

1. A variable that is the name of a dynamic formal parameter.
2. A call to a function whose return value is dynamic.
3. An if-then-else where the condition and/or either branch is dynamic.
4. A unary or binary operator where one or both operands are dynamic.

Specializing a functional program is similar to specializing a procedural program. Both use a worklist to keep track of components that need to be specialized; both can sometimes create copies of components that are "specialized in place"; and both can sometimes create copies of components with new "names" that are based on the values of static variables.

Specializing "in place": For a procedural program, if the current basic block ends with an unconditional goto (or a static, conditional goto), we simply add the specialized version of the target block to the end of the current basic block. The analogy for the functional case is that when the current expression is a call to a function whose return value is static, we simply replace the function call with the specialized version of that function's body (using the values of the actual parameters, which will be static, in place of instances of the function's formal parameters).

Specializing a new copy whose "name" is based on static values: We have a similar analogy for the way conditional gotos with dynamic conditions are handled in the procedural case. In the procedural case, we change the goto targets to new labels that include the current static values, and we put those new labels on a worklist. The corresponding functional case occurs when there is a call to a function whose return value is dynamic. In this case, we replace the call with a call to a new function whose name includes the values of the static actuals, and we put that name on our worklist.

Here is a table that summarizes the different aspects of partial evaluation for the procedural and functional cases.

	Procedural	Functional
what BTA classifies	variables	variables (formals), function returns, expressions
what's in the worklist	labels of the form <oldLabel><list of static-vars' values>	fn names of the form <origName><list of static-parameters' values>
what's processed (specialized)	each statement of the current basic block	each (sub)expression of the current fn
what may be copied and specialized "in place"	a basic block that is the target of an unconditional goto, or of a conditional goto w/ a static condition	a fn whose formals and return are all static
what may be copied and have multiple specialized versions with new names	a basic block that is the target of a conditional goto w/ a dynamic condition	a fn w/ a dynamic return

For our example functional program, the specialization phase would create the residual program shown below. In this case, there are three instances of new versions of functions whose names include the values of the static formals, and there is no instance of a function being specialized "in place" (because function find has a dynamic return). In this example, there is only one call to each of the three new functions. In general, it is possible to have multiple calls to new functions, just as, in the procedural case, it is possible to have multiple jumps to a new label.

(define (main valueList)
  (call find-"ann"-["susan" "john" "ann"] valueList)
)

(define (find-"ann"-["susan" "john" "ann"] vList)
  (call find-"ann"-["john" "ann"] (cdr vList))
)

(define (find-"ann"-["john" "ann"] vList)
  (call find-"ann"-["ann"] (cdr vList))
)

(define (find-"ann"-["ann"] vList)
  (car vList))
)