I don't like the changing of the state to PREMONOMORPHIC much. That seems
like a
very indirect way to get the computation of a monomorphic stub.
Other than that, LGTM.
http://codereview.chromium.org/6344005/diff/17001/src/arm/stub-cache-arm.cc
File src/arm/stub-cache-arm.cc (right):
http://codereview.chromium.org/6344005/diff/17001/src/arm/stub-cache-arm.cc#newcode1337
src/arm/stub-cache-arm.cc:1337: extra_ic_state_);
Needs updating to follow ia32.
http://codereview.chromium.org/6344005/diff/17001/src/ic.cc
File src/ic.cc (right):
http://codereview.chromium.org/6344005/diff/17001/src/ic.cc#newcode657
src/ic.cc:657: if (kind_ == Code::CALL_IC && state == MONOMORPHIC) {
This is non-trivial and requires a comment.
Would it be clearer to not change the state to PREMONOMORPHIC here and
handle this as part of the MONOMORPHIC case below? Refactor to get a
method to generate monomorphic stubs and call it from the PREMONOMORPHIC
and the MONOMORPHIC cases below?
http://codereview.chromium.org/6344005/diff/17001/src/type-info.cc
File src/type-info.cc (right):
http://codereview.chromium.org/6344005/diff/17001/src/type-info.cc#newcode125
src/type-info.cc:125: Code::kNoExtraICState,
This mean that we cannot get type feedback for the receiver if there
have been out of bounds reads? That could still be useful, couldn't it?
At least I think it requires a comment.
http://codereview.chromium.org/6344005/diff/17001/src/x64/stub-cache-x64.cc
File src/x64/stub-cache-x64.cc (right):
http://codereview.chromium.org/6344005/diff/17001/src/x64/stub-cache-x64.cc#newcode1332
src/x64/stub-cache-x64.cc:1332: extra_ic_state_);
Needs updating to follow ia32.
http://codereview.chromium.org/6344005/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
