Make DeltaBlue performance more stable by ignoring type feedback that
tells us that a map can transition to another map when we are generating code for load operations. This may cause us to deopt if the same routine is seeing different maps caused by branching in constructors. If so, I have a different change that is around 100 times more complicated that lets us generated Crankshaft code for negative lookups. Review URL: https://chromiumcodereview.appspot.com/10306010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11524 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This commit is contained in:
parent
2cb65b13be
commit
29c48e1076
@ -1603,6 +1603,7 @@ HLoadNamedFieldPolymorphic::HLoadNamedFieldPolymorphic(HValue* context,
|
||||
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,20 @@ HLoadNamedFieldPolymorphic::HLoadNamedFieldPolymorphic(HValue* context,
|
||||
case CONSTANT_FUNCTION:
|
||||
types_.Add(types->at(i));
|
||||
break;
|
||||
case MAP_TRANSITION:
|
||||
// We should just ignore these since they are not relevant to a load
|
||||
// operation. This means we will deopt if we actually see this map
|
||||
// from optimized code.
|
||||
map_transitions++;
|
||||
break;
|
||||
default:
|
||||
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();
|
||||
|
Loading…
Reference in New Issue
Block a user