I think it's getting clearer. My big concern is still that it's too
different
from the other inline caching mechanism.
I think my problem is this: we have two kinds of stubs (1) inline cache
stubs we
use for performance, which inherit from class IC and are passed based on
runtime
type information and (2) shared code stubs we use to reduce code size, which
inherit from class CodeStub and are not patched.
This change is complicated, because it combines the two. Perhaps it would
be
better to introduce a new class of BinaryOpIC inline chache stubs instead of
trying to patch the existing GenericBinaryOpStub code stubs. I think that
would
be conceptually clearer.
http://codereview.chromium.org/553117/diff/2001/3014
File src/code-stubs.h (right):
http://codereview.chromium.org/553117/diff/2001/3014#newcode141
src/code-stubs.h:141: virtual int GetCodeKind();
This should return Code::Kind.
http://codereview.chromium.org/553117/diff/2001/3014#newcode144
src/code-stubs.h:144: virtual int GetICState();
This should return InlineCacheState.
http://codereview.chromium.org/553117/diff/2001/3008
File src/debug.cc (right):
http://codereview.chromium.org/553117/diff/2001/3008#newcode1367
src/debug.cc:1367: UNREACHABLE();
This whole block of code should be cleaned up to use a switch over
code->kind().
http://codereview.chromium.org/553117/diff/2001/3003
File src/ia32/codegen-ia32.h (right):
http://codereview.chromium.org/553117/diff/2001/3003#newcode31
src/ia32/codegen-ia32.h:31: #include "ic-inl.h"
Is there a reason this can't be #include "ic.h"?
http://codereview.chromium.org/553117
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
