Value Numbering

1. Another important optimization technique is common subexpression elimination. The goal of this optimization is to identify expressions that are guaranteed to produce identical values at runtime and arrange to only performed the associated computation once (when the first instance of the expression is encountered).

2. This is a more interesting problem that constant folding because it involves tracking the flow of information through variables.

   • In the code:

     	    x = a + b;
     	    y = c + d;
     	    a = e;
                 z = a + b;
                 w = b + y;
                 v = b + c + d;
     	

     The two occurences of "a+b" are not common subexpressions because the value of a may change between the evaluation of the first and second copies of the expression. On the other hand, the last two expressions, "b + y" and "b + c + d" can be identified as common subexpressions even though they are not textually identical because they are guaranteed to produce identical values.

3. As a result, in a general implementation of CSE (common subexpression elimination), we have to take into account assignments to variables and control flow. We will begin by restricting our attention to CSE in straight line code. Then, once the details are understood, we can see how to deal with programs (like most real ones) that include control constructs.

4. Eliminating common sub-expressions involves two non-trivial sub-problems.

   • Expressions that look identical only produce the same results if none of the values of variables referenced by the two expressions may be changed between their evaluations.

   • Even if we only looked for examples of identical expressions, we would need to find an efficient way to look for matching subtrees.

   • Expressions that don't look identical may produce identical results:

     x = 1 + y;
     
     a[y + 1] = a[x] + 1
     		

5. The scheme we will use is called Value Numbering.

6. The idea is to traverse the expression sub-trees of a basic block assigning an identifying number to each sub-expression. The goal is to assign the same number to all expressions we can be sure will produce the same value.

7. The algorithm will be based on a form of table lookup. The table will associate expressions with their "value numbers". For each expression we encounter as we traverse the subtrees of a basic block we will.
   • Look the expression up in our table.
   • If the expression is not in out table, we will assign it the next unused value number (i.e. add one to the last one) and enter the expression/number pair in the table.
   • If an expression is already in the table, we will associate it with its already assigned value number.

8. The trick that makes this interesting is that we will use the numbers we assign to make our table lookups efficient.

   • We will actually partition our table into two parts.
     • For simple variables, since the refvar nodes in the syntax tree point directly to their declaration descriptors, we will simply store their value numbers in a new field within the descriptor.
     • The main table will be a hash table. It will be used for all expressions except references to simple variables.

9. We will account for assignments by changing value numbers appropriately.

   • In this scheme, variables used in expressions will be assigned value numbers when they are first encountered and (at least logically) be included in our table.

   • For each assignment encountered as we process a basic block, we will assign a new value number to the variable (and update our table) so that we will recognize that subsequent expressions that reference the variable may produce distinct values from earlier, syntactically identical expressions.

   • We don't assign brand new value numbers to the targets of assignments. Instead, when processing the assignment

     x := E

     we will assign E's value number to x since future references to x will produce the same value as E.

10. The hash table will map a key that uniquely identifies an expression's values to the expression's value number. The key used will depend on the form of the expression.

    • For binary operators, the key will be a triple composed of the operator type (i.e. the value of the type field of the root of the expression subtree) and the value numbers of the sub-expressions.

    • For unary operators, the key will be a pair consisting of an operator number and the sub-expression's value number.

    • For constant nodes, the key pair will consist of the node type (Nconst) and the constant's value.

    • Refvar subexpressions are interesting enough to deserve separate consideration below.

11. So, to process an expression, we:
    • process its sub-expressions (receiving their value numbers as return values),
    • build the appropriate key based on the expression type and the value numbers of its sub-expressions.
    • look the key up in the hash table, and
    • make a new table entry associating the key with the next value number if no match is found, or
    • recognize that we have found a CSE if a match is found (ard then return the associated value number).