Propagate class ids using existing type propagation framework.

runtime/vm/flow_graph_optimizer.cc

Index: runtime/vm/flow_graph_optimizer.cc
===================================================================
--- runtime/vm/flow_graph_optimizer.cc	(revision 10748)
+++ runtime/vm/flow_graph_optimizer.cc	(working copy)
@@ -672,6 +672,12 @@
   if (changed) {
     still_changing_ = true;
   }
+  // Propagate class ids.
+  intptr_t cid = bind->computation()->ResultCid();
+  changed = bind->SetPropagatedCid(cid);
+  if (changed) {
+    still_changing_ = true;
+  }
 }
 
 
@@ -686,6 +692,19 @@
   if (changed) {
     still_changing_ = true;
   }
+  if (phi->propagated_cid() == kDynamicCid) {

[regis, 2012/08/15 22:46:54]

So far, I have tried not to depend on the type of the result of the previous
iteration, but only on the types of the inputs in the current iteration.
In your case, it is not clear to me if a propagated cid could be dynamic in the
first iteration and change in a following one. I think it should be possible.

[srdjan, 2012/08/16 00:34:46]

Done.

+    return;
+  }
+  // Merge class ids: if any two inputs have different class ids than result

[regis, 2012/08/15 22:46:54]

s/than/then/

[srdjan, 2012/08/16 00:34:46]

Done.

+  // is kDynamicCid.
+  for (intptr_t i = 0; i < phi->InputCount(); i++) {
+    intptr_t cid = phi->InputAt(i)->ResultCid();
+    ASSERT(cid != kIllegalCid);
+    changed = phi->SetPropagatedCid(cid);

[regis, 2012/08/15 22:46:54]

This does not look right. You are not merging, but setting the cid of the last
input as the phi's cid.
OK, I understand now when looking at SetPropagatedCid(). See my comment there.

[srdjan, 2012/08/16 00:34:46]

Done.

+    if (changed) {
+      still_changing_ = true;
+    }
+  }
 }