Port r9977 (9aded78be4).
Note: This is the port of the reapplied patch, not the original.
Original commit message:
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.
BUG=
TEST=
Review URL: http://codereview.chromium.org/8557003
Patch from Gergely Kis <gergely@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r10006 (4b344a03).
Original commit message:
Changes the way we do lazy deoptimization:
1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.
CALL
GAP
LAZY-BAILOUT ==> lazy-deopt-call
2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.
STACK-CHECK
GAP ==> lazy-deopt-call
The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.
Additional changes:
* RegExpLiteral marked it as having side-effects so that it
gets an explicitlazy-bailout instruction (instead of
treating it specially like stack-checks)
* Enable target recording CallFunctionStub to achieve
more inlining on optimized code.
BUG=
TEST=
Review URL: http://codereview.chromium.org/8587008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10020 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
EmitIsObject is only called from one function, DoIsObjectAndBranch.
DoIsObjectAndBranch now passes the temp2 register to EmitIsObject
instead of simply relying on the two functions using the same
lithium scratch register.
BUG=
TEST=
Review URL: http://codereview.chromium.org/8588004
Patch from Gergely Kis <gergely@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10017 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changes:
-separated the two code-paths (constant power of 2 divisor similar to ARM and everything else)
-replaced a bailout condition with faster handling (negative modulo result)
-removed a possibly useless mov instruction from one path
-replaced the IsConstantOperand condition with the more meaningful HasPowerOf2Divisor (although in this specific case they're equivalent)
BUG=
TEST=
Review URL: http://codereview.chromium.org/8591002
Patch from Gergely Kis <gergely@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10016 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Changes the way we do lazy deoptimization:
1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.
CALL
GAP
LAZY-BAILOUT ==> lazy-deopt-call
2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.
STACK-CHECK
GAP ==> lazy-deopt-call
The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.
Additional changes:
* RegExpLiteral marked it as having side-effects so that it
gets an explicitlazy-bailout instruction (instead of
treating it specially like stack-checks)
* Enable target recording CallFunctionStub to achieve
more inlining on optimized code.
BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
So far free variables references in eval code are not statically
resolved. For example in
function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.
The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.
This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.
This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft reads:
* It is a Syntax Error if the AssignmentExpression is contained in extended
code and the LeftHandSideExpression is an Identifier that does not
statically resolve to a declarative environment record binding or if the
resolved binding is an immutable binding.
TEST=existing tests in mjsunit
Review URL: http://codereview.chromium.org/8508052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
