Thanks for the comments. I uploaded new patch set.
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (right):
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/ia32/lithium-codegen-ia32.cc#newcode5338
src/ia32/lithium-codegen-ia32.cc:5338: if
(maps->at(i)->is_dictionary_map()) can_ommit_checks = false;
On 2013/02/11 12:23:45, Toon Verwaest wrote:
This could should really go somewhere else; probably in the map. Add a
utility
method Map::CanOmitPrototypeChecks or so.
Done. After discussion with Jakob, I moved the loop above into a method
of the hydrogen instruction to make it platform independent.
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/objects.cc
File src/objects.cc (right):
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/objects.cc#newcode5296
src/objects.cc:5296:
DeoptimizeDependentCodes(DependentCodes::kPrototypeCheckGroup);
On 2013/02/11 12:23:45, Toon Verwaest wrote:
Placing this in CopyDropDescriptors is probably a bit too
heavy-weight, given
that you only care about this when transitions are added. I presume
you could
rather use the Map::AddTransition api as entry-point to deoptimize. It
already
special-cases for the case that you are adding the first transition.
As discussed offline, adding abstraction function here to track object
layout changes that not necessarily lead to AddTransition.
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/objects.cc#newcode9581
src/objects.cc:9581: }
On 2013/02/11 12:23:45, Toon Verwaest wrote:
I guess the if(!..) { } is not necessary; since after you go over it,
it'll
always be set to true. I presume set_marked doesn't trigger extra
computation
given that it's lowercase; but if it does, you could move the
condition in that
method.
Done.
https://chromiumcodereview.appspot.com/12225099/diff/4001/src/objects.cc#newcode9582
src/objects.cc:9582: }
On 2013/02/11 12:23:45, Toon Verwaest wrote:
I don't particularly like this API. It seems like we'd want to have an
iterator
here. Also codes->Compute...(starts) seems a bit odd. Why not just
::GroupStartIndexes starts(codes) and let the constructor compute?
Done.
https://chromiumcodereview.appspot.com/12225099/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
