Now with arm and x64 support. Additionally, added default unreachable case to switch statement in CompareIC::TargetState to make win and mac compilers happy.
Reviewer guide:
This is an exact copy of 10216 except:
src/arm/*
src/x64/*
src/ic.cc (added default case to swith in CompareIC::TargetState)
Review URL: http://codereview.chromium.org/8872060
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This includes specialcasing the generation when we know that the maps
of the two objects are the same. In addition, a new specialized
compare ic known objects cache is created.
The reason for the cache is that we need to have access to the stub
code from the roots; if we do not, the GC will collect the stub. In
this specialized case we use the map pointer as key in the cache, and
we always do a lookup before generating code. Actually hitting
something in the cache will happen very rarely, but we could
potentially overwrite an existing stub, which again will lead to the
GC collecting this old stub (even if it is referenced from other code
objects)
Review URL: http://codereview.chromium.org/8520006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10216 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original commit message:
Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8538011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8462010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) Don't make a call to C without having a valid frame on the stack.
2) Don't generate a call to a stub while generating a stub, unless we can be
sure that the stub we are calling has already been generated (the stub
generation code is not reentrant wrt. GC).
Review URL: http://codereview.chromium.org/7891042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9297 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changing our builtin JavaScript code slightly, we can make sure that we never
see internal objects as arguments for ToBoolean at runtime. Removing that case
from the stub generator and crankshaft makes things a lot easier.
Heap numbers can never be undetectable (only strings and spec objects can), so
we can leave out a useless test.
Try to re-use a non-null register value when returning 'true' in some cases.
Removed special handling of the 'handle all' case, it will very probably never
happen in real code and only makes things more complicated.
Improved naming of the ToBoolean stubs a bit, reflecting the order in which
cases are handled in the code itself.
Review URL: http://codereview.chromium.org/7497063
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8886 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To do this, the Branch instruction needs to carry around a temporary register,
but only when the crankshafted code will make a map access. When the
crankshafted code sees an object of a type it hasn't encountered before, it will
always trigger a deopt. Another option in theses cases would be calling a
ToBooleanStub which can handle all types, but then one has to be careful to
*not* trigger a GC (which is currently a bit tricky to achieve).
Const-corrected ToBoolean::Types. Moved the NeedsMap logic into ToBoolean::Types
itself, where it belongs.
This patch improves a lot of benchmarks, crypto-orig even by 16.7%, but slows
down others. The slowdown has to be investigated, but I'd like to get this patch
out first to fix the flakiness problems we currently have due to the previous
crankshafted ToBoolean.
Review URL: http://codereview.chromium.org/7461107
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8758 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Loading the map within the stub already implies a check for an undetectable
object, so there is no need to record this separately. Furthermore, this brings
the size of the type info to record down to 8 bits, removing the need to find a
place for the ninth bit in the Code object. ;-)
Review URL: http://codereview.chromium.org/7484022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8722 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The IC records the set of types it has seen, e.g. {String} or {Boolean,
Undefined}, etc. Note that in theory this could lead to a large number of
different ToBoolean ICs (512, to be exact, because we distinguish 9 types),
but in practice only a small handful of them are actually generated.
Currently the type recording part is only implemented on ia32, other platforms
continue to work like they did before, though.
Removed some dead code on the way.
Review URL: http://codereview.chromium.org/7473028
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8716 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Using a C++-style method PrintName (a.k.a. << ;-), things get a lot easier when
two unrelated concerns are separated. Stubs don't need a name cache anymore,
simpler code while generating the stub name, memory allocation is centralized,
etc.
Review URL: http://codereview.chromium.org/7342042
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8627 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Better support for 'polymorphic' JS and external arrays
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps and dispatches to shared stubs to perform the array operation.
Review URL: http://codereview.chromium.org/7036016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7935 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Allow keyed store/load stubs to switch between external array and fast JS arrays without forcing a state transition to the generic stub.
There CL consists of two pieces of functionality. First, code stubs for fast element arrays don't immediately transition to the MEGAMORPHIC state when there's a map mismatch. Second, two ICs are cached per map for fast elements, the MONOMORPHIC version, and a new MEGAMORPHIC version that handles two or more different maps. Currently, the only array types supported by the MEGAMORPHIC stub are fast elements for objects and JSArrays.
BUG=
TEST=
Review URL: http://codereview.chromium.org/6894003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7917 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Non-moveable code-stube are allocated in large object space. They are only required on ARM where the different C-entry stubs are required to never move.
This gets rid of pre-computing these stubs and hope that they never move. Also for crankshaft the C-entry stub which saved doubles is not generated in the snapshot so it ends up being generated at runtime and potentially move.
Review URL: http://codereview.chromium.org/6626072
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7097 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
