Added VariableUse expression to tree IR.

pkg/compiler/lib/src/tree_ir/optimization/copy_propagator.dart

 // Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 part of tree_ir.optimization;
 
 /// Eliminates moving assignments, such as w := v, by assigning directly to w
 /// at the definition of v.
 ///
 /// This compensates for suboptimal register allocation, and merges closure
@@ skipping 91 matching lines @@
 
   Statement visitBasicBlock(Statement node) {
     node = visitStatement(node);
     move.clear();
     inverseMove.clear();
     return node;
   }
 
   void visitVariable(Variable variable) {
     // We have found a use of w.
     // Remove assignments of form w := v from the move maps.

[Kevin Millikin (Google), 2015/02/26 12:43:18]

It looks like we remove variable's that are read and variables that are written
for slightly different reasons.  We remove the assignment in '... w ... w := v'
because adding an assignment to w before that would add one that reaches the
read of w.  And we remove the second assignment in '... w := v0 ... w := v1'
because adding an assignment to w before that would add one that doesn't reach
the use (formerly v1).

I think that would be clearer if the was something like 'removeAssignment' or
'invalidateAssignment' and it was called directly with a comment explaining why
at the two call sites.  (I'm not a fan of visitVariable :) )

[asgerf, 2015/02/27 12:05:19]

Completely agree.

     Assign movingAssignment = inverseMove.remove(variable);
     if (movingAssignment != null) {
-      move.remove(movingAssignment.definition);
+      VariableUse def = movingAssignment.definition;
+      move.remove(def.variable);
     }
   }
 
   /**
    * Called when a definition of [v] is encountered.
    * Attempts to propagate the assignment through a moving assignment.
    * Returns the variable to be assigned into, defaulting to [v] itself if
    * no optimization could be performed.
    */
   Variable copyPropagateVariable(Variable v) {
     Assign movingAssign = move[v];
     if (movingAssign != null) {
       // We found the pattern:
       //   v := EXPR
       //   BLOCK   (does not use w)
       //   w := v  (only use of v)
       //
       // Rewrite to:
       //   w := EXPR
       //   BLOCK
       //   w := w  (to be removed later)
       Variable w = movingAssign.variable;
 
       // Make w := w.
       // We can't remove the statement from here because we don't have
       // parent pointers. So just make it a no-op so it can be removed later.
-      movingAssign.definition = w;
+      movingAssign.definition = new VariableUse(w);
 
       // The intermediate variable 'v' should now be orphaned, so don't bother
       // updating its read/write counters.
-      // Due to the nop trick, the variable 'w' now has one additional read
-      // and write.
-      ++w.writeCount;
-      ++w.readCount;
+      // Due to the nop trick, the variable 'w' now has one additional write.

[Kevin Millikin (Google), 2015/02/26 12:43:18]

'The nop trick' is a bit confusing.  Isn't the extra write because in the case
where we return w and not v, we will add an assignment to w (in the caller of
copyPropagateVariable)?

Is it possible to make a setter for Assign.variable that will update the write
count when the variable is changed?

[asgerf, 2015/02/27 12:05:19]

Yeah, that's why I moved it closer to the return. I forgot to remove the
comment.

Using getters/setters to update reference counts might give a false sense of
security since it still does not decrement counts when a node gets orphaned.
Then we would need a call a destroy() method to indicate when a node has been
removed. At the end of the day, I don't think it buys us a lot. Or maybe I just
have a preference for working with "raw data" rather than "smart objects".

[Kevin Millikin (Google), 2015/02/27 12:17:18]

I'm on the fence.  It's definitely a downside of trying to be too smart that you
end up with a bunch of similarly-named helpers that do things just slightly
differently (like if you ever need a different order, or to not do some of the
updates, or whatever).

I'm satisfied with leaving this explicit.

 
       // Make w := EXPR
+      ++w.writeCount;
       return w;
     }
     return v;
   }
 
   Statement visitAssign(Assign node) {
     node.next = visitStatement(node.next);
     node.variable = copyPropagateVariable(node.variable);
     visitExpression(node.definition);
     visitVariable(node.variable);
 
     // If this is a moving assignment w := v, with this being the only use of v,
     // try to propagate it backwards.  Do not propagate assignments where w
     // is from an outer function scope.
-    if (node.definition is Variable) {
-      Variable def = node.definition;
-      if (def.readCount == 1 &&
+    if (node.definition is VariableUse) {
+      VariableUse definition = node.definition;
+      if (definition.variable.readCount == 1 &&
           node.variable.host == currentElement) {
-        move[node.definition] = node;
+        move[definition.variable] = node;
         inverseMove[node.variable] = node;
       }
     }
 
     return node;
   }
 
   Statement visitLabeledStatement(LabeledStatement node) {
     node.next = visitBasicBlock(node.next);
     node.body = visitStatement(node.body);
@@ skipping 52 matching lines @@
 
   void visitFunctionExpression(FunctionExpression node) {
     new CopyPropagator().rewrite(node.definition);
   }
 
   void visitFieldInitializer(FieldInitializer node) {
     visitStatement(node.body);
   }
 
 }