Description:
Add support for lazy deoptimization from deferred stack checks
The debugger can be entered from the deferred stack check in optimized code.
This can cause both lazy deoptimization and debugger deoptimization
(setting the
first break point and inspecting the stack for optimized code respectively).
This required deoptimization support from the deferred stack check.
The lazy deoptimiztion call is inserted when the deferred code is done
including
restoring the registers. The bailout to the full code is the begining of the
loop body as that is where the stack check is sitting in the optimized
code. The
bailout is not to the stack check in the full code as that is sitting at
the end
of the loop.
BUG=none
TEST=none
Please review this at http://codereview.chromium.org/7212025/
SVN Base: https://v8.googlecode.com/svn/branches/bleeding_edge
Affected files:
M src/arm/lithium-codegen-arm.cc
M src/ast.h
M src/hydrogen.h
M src/hydrogen.cc
M src/ia32/lithium-codegen-ia32.cc
M src/x64/lithium-codegen-x64.cc
M test/cctest/test-debug.cc
http://codereview.chromium.org/7212025/diff/1/src/ia32/lithium-codegen-ia32.cc#newcode273
src/ia32/lithium-codegen-ia32.cc:273: // have room for lazy bailout.
I don't understand why the last piece of deferred code is special in the
need for some room for lazy bailout. Is the last piece special? If it
is special, this seems fragile. Perhaps in the future the deferred code
fragments get sorted in some way, e.g. to optimize the number of exit
jumps that can be in the short form. If the last piece of code is
always a certain kind of deferred code, the deferred code Generate
method should allocate the nops.
Please take a look at http://codereview.chromium.org/7277081/.
This change invalidates your assumption that the deferred code ends in a
jump to the exit label.
You can still make the deferred stack check end with a jump but please
don't force that constraint on other deferred code fragments. The
constraint is adding 2-3% extra code size.