Polymorphic inlining for some recognized methods in the optimizing compiler.

runtime/vm/compiler.cc

Index: runtime/vm/compiler.cc
===================================================================
--- runtime/vm/compiler.cc	(revision 25997)
+++ runtime/vm/compiler.cc	(working copy)
@@ -338,6 +338,17 @@
         optimizer.TryOptimizeLeftShiftWithBitAndPattern();
         DEBUG_ASSERT(flow_graph->VerifyUseLists());
 
+        // Propagate types and eliminate more type tests.
+        if (FLAG_propagate_types) {
+          FlowGraphTypePropagator propagator(flow_graph);
+          propagator.Propagate();

[Kevin Millikin (Google), 2013/08/13 11:47:40]

Why?

We compute this five times.  The other four have a comment explaining why they
are called there, this one just has the same comment as the next one.

I'm guessing that it is necessary now for inlining?  If that's the case, can't
it be moved inside if (FLAG_use_inlining)?  (When !FLAG_use_inlining, we
propagate types and apply class ids twice in a row).

[Florian Schneider, 2013/08/14 12:30:24]

Without this I get some performance regressions where propagating types before
inlining helps. I'll move it inside the if-statement.

+          DEBUG_ASSERT(flow_graph->VerifyUseLists());
+        }
+
+        // Use propagated class-ids to optimize further.
+        optimizer.ApplyClassIds();
+        DEBUG_ASSERT(flow_graph->VerifyUseLists());
+
         // Inlining (mutates the flow graph)
         if (FLAG_use_inlining) {
           TimerScope timer(FLAG_compiler_stats,