Make DeltaBlue performance more stable by ignoring type feedback that

src/hydrogen-instructions.cc

Index: src/hydrogen-instructions.cc
===================================================================
--- src/hydrogen-instructions.cc	(revision 11473)
+++ src/hydrogen-instructions.cc	(working copy)
@@ -1603,6 +1603,7 @@
   SetOperandAt(1, object);
   set_representation(Representation::Tagged());
   SetGVNFlag(kDependsOnMaps);
+  int map_transitions = 0;
   for (int i = 0;
        i < types->length() && types_.length() < kMaxLoadPolymorphism;
        ++i) {
@@ -1624,13 +1625,19 @@
         case CONSTANT_FUNCTION:
           types_.Add(types->at(i));
           break;
+        case MAP_TRANSITION:

[Michael Starzinger, 2012/05/02 13:39:29]

I think that check is not general enough. We have a transition whenever
"lookup.IsFound() && !lookup.IsProperty()". Esepcially with Sven's new accessor
pairs in mind.

[Sven Panne, 2012/05/02 13:55:00]

Michael's comment is correct, but things are even more tricky, because the
PropertyType alone is not enough to decide if we have a transition or not: In
the CALLBACKS case you have to look into the AccessorPair to decide if we have a
transition or not. And without a holder (see "NULL" above), this won't work...
(see LookupResult::IsProperty).

[Erik Corry, 2012/05/03 10:39:14]

All I want to do is to ignore this particular map when generating optimized
code.  If we actually encounter it we will deopt.  I don't actually care much
whether there is a real map transition from this map to another one.

+          // We should just ignore these since they are not relevant to a load
+          // operation.

[Michael Starzinger, 2012/05/03 14:12:22]

In this case, this comment should contain something like "... and possibly
deoptimize in these cases".

+          map_transitions++;
+          break;
         default:

[Sven Panne, 2012/05/02 13:55:00]

We should never use a default case when doing a switch over the property type,
because this makes finding all the places where things have to be changed when
fiddling around with those types (e.g. adding a new type, changing the behaviour
for a given type, etc.) virtually impossible. I've been down that road several
times in the last few months... :-P

[Erik Corry, 2012/05/03 10:39:14]

I didn't add this default clause.  All it is saying is that if there is another
kind of property then Crankshaft does not understand it and will not generate
optimized code for it.  If a new kind of property is added this is certainly the
correct behaviour, so I see no reason to change this, but you are welcome to try
in a different CL.

           break;
       }
     }
   }
 
-  if (types_.length() == types->length() && FLAG_deoptimize_uncommon_cases) {
+  if (types_.length() + map_transitions == types->length() &&
+      FLAG_deoptimize_uncommon_cases) {
     SetFlag(kUseGVN);
   } else {
     SetAllSideEffects();