(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1668103002

Cr-Commit-Position: refs/heads/master@{#33741}

This implements proper context switching while unwinding the stack due
to an exception being handled in interpreted code. The context under
which the handler is scoped is being preserved in a dedicated register
while the try-block is running. Both, the stack unwinding machinery as
well as the graph builder, restore the context from that register.

R=rmcilroy@chromium.org,bmeurer@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1665833002

Cr-Commit-Position: refs/heads/master@{#33733}

Moves the stack check from the function entry trampoline to instead be
after function activation using an explicit StackCheck bytecode. Also
add stack checks on back edges of loops.

BUG=v8:4280,v8:4678
LOG=N

Review URL: https://codereview.chromium.org/1665853002

Cr-Commit-Position: refs/heads/master@{#33730}

Adds implementation and tests for with statement to interprter.

BUG=v8:4280,v8:4684
LOG=N

Review URL: https://codereview.chromium.org/1656863002

Cr-Commit-Position: refs/heads/master@{#33705}

BUG=chromium:583260
LOG=n

Review URL: https://codereview.chromium.org/1664683002

Cr-Commit-Position: refs/heads/master@{#33697}

Set the bytecode array correctly in Runtime_SetCode.
This fixes issues with building the snapshot with ignition enabled.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1647913002

Cr-Commit-Position: refs/heads/master@{#33638}

In the debugger we are interested in getting the context for the
current frame, which is usually a function context. To do that,
we used to call Context::declaration_context, which may also
return a block context. This is wrong and can lead to crashes.
Instead, we now use a newly introduced Context::closure_context,
which skips block contexts. This works fine for the debugger,
since we have other means to find and materialize block contexts.

R=rossberg@chromium.org
BUG=chromium:582051
LOG=N

Review URL: https://codereview.chromium.org/1648263002

Cr-Commit-Position: refs/heads/master@{#33627}

This translates the exception handler table attached to a bytecode array
correctly into exceptional projections within the TurboFan graph. We
perform an abstract simulation of handlers that are being entered and
exited by the bytecode iteration to track the correct handler for each
node.

R=oth@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1641723002

Cr-Commit-Position: refs/heads/master@{#33580}

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1643533003

Cr-Commit-Position: refs/heads/master@{#33556}

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1642613002

Cr-Commit-Position: refs/heads/master@{#33548}

BUG=v8:4586
LOG=n

Review URL: https://codereview.chromium.org/1631333002

Cr-Commit-Position: refs/heads/master@{#33542}

BUG=v8:2952
LOG=N

Review URL: https://codereview.chromium.org/1599303002

Cr-Commit-Position: refs/heads/master@{#33538}

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1632993003

Cr-Commit-Position: refs/heads/master@{#33520}

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

Review URL: https://codereview.chromium.org/1563213002

Cr-Commit-Position: refs/heads/master@{#33518}

BUG=v8:4280
LOG=N
TBR=machenbach@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1633133002

Cr-Commit-Position: refs/heads/master@{#33517}

This increases the size of register operands to be 16-bit.

Not all bytecodes have wide register variants, so when they are
needed a register translator will copy them into a small area
reserved at the top of the 8-bit register range and these registers
are supplied as arguments to the bytecode with 8-bit operands.

This is non-intrusive for typical bytecode where the number of
registers is less than 120. For bytecodes with wide register
operands (above the window) their index needs to be translated
to avoid the reserved translation window.

Enables splay.js to run in Octane and a handful of mjsunit tests.

BUG=v8:4280,v8:4675
LOG=NO

Review URL: https://codereview.chromium.org/1613163002

Cr-Commit-Position: refs/heads/master@{#33516}

This CL disables a test that takes too long in debug mode when
escape analysis is enabled in turbofan.

R=machenbach@chromium.org
BUG=v8:4586
LOG=n
NOTRY=true

Review URL: https://codereview.chromium.org/1636593004

Cr-Commit-Position: refs/heads/master@{#33514}

Rename IntepreterExceptionEntryHandler builtin to InterpreterEnterBytecodeDispatch
and use it as the return address when building interpreter frames during deopt.
This ensures that we restart execution of the outer frame at the correct
bytecode.

BUG=v8:4280,v8:4678
LOG=N

Review URL: https://codereview.chromium.org/1633633002

Cr-Commit-Position: refs/heads/master@{#33512}

Adds support for calling native function literals. Moves the logic for building
the native function's SharedFunctionInfo out of full-codegen into compiler.cc
to allow it to be shared between fullcodegen and Ignition.

BUG=v8:4686
LOG=N

Review URL: https://codereview.chromium.org/1635553002

Cr-Commit-Position: refs/heads/master@{#33510}

BUG=chromium:580506
LOG=N

Review URL: https://codereview.chromium.org/1631673002

Cr-Commit-Position: refs/heads/master@{#33497}

This fixes corner cases where the start offsets of exception handler
regions within the handler table fall together. This assumption was
based on full-codegen code and no longer holds with the interpreter.
The tables however are still well nested and code has been added to
verify that in debug mode.

R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1633573002

Cr-Commit-Position: refs/heads/master@{#33495}

The current support for try-catch in the interpreter can handle most of
the cases appearing in our test suite. Also the flag in question did not
detect try-finally constructs. This removes the flag and instead extends
the test expectations.

R=rmcilroy@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1631593003

Cr-Commit-Position: refs/heads/master@{#33494}

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1627943003

Cr-Commit-Position: refs/heads/master@{#33489}

These tests have been disabled while support for try-finally was work in
progress. By now control flow is connected properly and the tests pass.

R=oth@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1626503002

Cr-Commit-Position: refs/heads/master@{#33474}

NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1621523003

Cr-Commit-Position: refs/heads/master@{#33457}

BUG=v8:4696
LOG=N
NOTRY=true
TBR=rossberg, nickie

Review URL: https://codereview.chromium.org/1617803004

Cr-Commit-Position: refs/heads/master@{#33445}

This implements a first prototype of stack unwinding for interpreted
frames. The unwinding machinery performs a range-based lookup in the
given handler table and potentially continues dispatching at the handler
offset. Note that this does not yet correctly restore the context to the
correct value when the handler is being entered.

R=rmcilroy@chromium.org,oth@chromium.org
BUG=v8:4674
LOG=n

Review URL: https://codereview.chromium.org/1605633003

Cr-Commit-Position: refs/heads/master@{#33414}

This is to fix some of the failing test262 tests with ignition flag.
In few test262 tests, there is a throw from the script scope. Rewriter::Rewrite
pass converts expression statements into assignment statements in script scope.
This causes interpreter to fail because assignment expression expects a result
in accumulator but throw statement does not return a value. To fix this, we
now mark that accumulator contains a value when visiting throw statement.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1523423003

Cr-Commit-Position: refs/heads/master@{#33408}

Now that we support eval in Ignition, remove the fallback for eval checks
and make the flag only fallback on catch blocks.

BUG=v8:4280,v8:4676
LOG=N

Review URL: https://codereview.chromium.org/1595223004

Cr-Commit-Position: refs/heads/master@{#33384}

R=jkummerow@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1603683002 .

Cr-Commit-Position: refs/heads/master@{#33375}

LOG=Y
BUG=chromium:575167

Review URL: https://codereview.chromium.org/1576953002

Cr-Commit-Position: refs/heads/master@{#33372}

VisitObjectLiteral has two parts. First it creates a literal and then
sets properties or accessor properties. Setting properties requires a
runtime call and it expects the literal object which was created in the
first part is contiguous with other registers it allocates. Since these
are allocated in a different scope they are not always contiguous.
This causes problems with mjsunit/setter-on-constructor-prototype.js.
This cl fixes by allocating contiguous registers in the inner scope.
Literal value is copied into the newly allocated register so that all
the required registers are always contiguous.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1588903002

Cr-Commit-Position: refs/heads/master@{#33371}

When derived constructors return a non-object (or not undefined) we
currently throw an exception directly in the callee context. This was
achieved by desugaring the return statement for derived classes. To
be spec compliamnt a separate ConstructStubForDerived is introduced.
Instead of trowing directly, the desugared return statement inside
a derived constructor only returns an integer to indicate an incompatible
result.

BUG=v8:4509
LOG=n

Review URL: https://codereview.chromium.org/1593553002

Cr-Commit-Position: refs/heads/master@{#33336}

BUG=v8:4280
LOG=N
TBR=machenbach@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1582273005

Cr-Commit-Position: refs/heads/master@{#33331}

Remove ignition skips which are fixed by https://chromium.googlesource.com/v8/v8/+/48a3227b7dd2f285aa599eb1cdf5f8bc94acdec7.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1590513003

Cr-Commit-Position: refs/heads/master@{#33322}

This avoids generating different scopes on the two compilation passes, which
results in various delirious side-effects.

There's some cleanup to be done in lazy arrow function parsing, but I'd
rather do that in a separate patch, with this one targeted at fixing the
particular crash.

BUG=chromium:572589
LOG=n

Review URL: https://codereview.chromium.org/1575333004

Cr-Commit-Position: refs/heads/master@{#33311}

Split RegisterAllocationScope out of ExpressionResult and allocate one
for each statement. This ensures that we always have an outer register
allocation scope for statement code (used in CountOperation and
RegisterExecutionResult). Also refactored the register allocator code to
move it to it's own file and rename from TemporaryRegisterScope to
BytecodeRegisterAllocator.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1587033002

Cr-Commit-Position: refs/heads/master@{#33296}

BUG=chromium:575080
LOG=N

Review URL: https://codereview.chromium.org/1579603002

Cr-Commit-Position: refs/heads/master@{#33288}

Removes assignment hazard scope. Reverts back to the naive scheme of
allocating a temporary for every variable load. It was decided to revert it
because the current implementation does not handle logical expressions,
ternary operators, visiting objects in named/keyed loads. Also, we wanted
to evaluate alternate approaches and choose one when we have a mechanism
to measure performance.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1576403004

Cr-Commit-Position: refs/heads/master@{#33269}

NOTRY=true
TBR=rmcilroy@chromium.org, neis@chromium.org

Review URL: https://codereview.chromium.org/1574343002

Cr-Commit-Position: refs/heads/master@{#33247}