This CL allows builtin continuations to handle pending exceptions.
This implements exception handling for the promise constructor in
case of deoptimization.

Bug: v8:7584


Change-Id: Ib5df5eb6606abb3f9690f294397981858dbdbf25
Reviewed-on: https://chromium-review.googlesource.com/983912
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52340}

This makes the inlining of the default resolve/reject closures generated
by the Promise constructor effective. To be really useful we still need
to have the Promise constructor inlined (work-in-progress) and eventually
track SharedFunctionInfo feedback in the CALL_IC.

Bug: v8:2206, v8:7253
Change-Id: I08fa8ca72754f459ae36027a55377ef57d411cdc
Reviewed-on: https://chromium-review.googlesource.com/926103
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51390}

Bug: v8:7340
Change-Id: I7f4df794a57bf5db6a3b611ad76b5ef5c4edba9c
Reviewed-on: https://chromium-review.googlesource.com/878264Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50785}

Previously StaNamedProperty and StaKeyedProperty were in a weird state where
they claimed to not touch the accumulator, but actually did in case they were
deopted in the middle. A frame was added in the middle to overwrite the 
accumulator again with the right value before returning from the setter, using
a lot of complexity in the deoptimizer.

This changes those instructions to be marked as writing to the accumulator
(e.g., the result of the setter), and uses to manually store and reload into
the accumulator the value being stored.

If we want to avoid the additional bytecodes, we could make sure that bytecodes
that claim to leave the accumulator alone don't deopt back to Advance/Dispatch
but LoadAccumulatorWithValue/Advance/Dispatch. That's in a way similar to what
happened before this CL, but I believe could be implemented much simpler.


Bug: 
Change-Id: I4850a690ef5a30976701d0e050951faa46fd1c18
Reviewed-on: https://chromium-review.googlesource.com/753487Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49159}

The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.

Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}

With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.

Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}

This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.

R=jarin@chromium.org
BUG=v8:6409

Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}

This CL contains a few pieces:

- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
  graphs, which--when triggered--swizzle the values in the the FrameState to be
  parameters to a typically TF-generated builtin that resumes execution to finish
  the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
  new frame type to ensure that the values they need to begin executing can be stashed
  away and restored immediately before the builtin is called via a trampoline that runs
  when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
  inline it. The inlined forEach implementation uses the checkpoints mechanism
  described above to deopt in the middle of the forEach in the cases that optimization
  invariants are violated. There is a slightly different continuation stub for each
  deopt point in the forEach implementation to ensure the correct side-effects, i.e.
  that the deopt of the builtin isn't programmatically observable.

Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}

BUG=v8:5402

Change-Id: If5f763e6a11d446e36719277a18b00a0cd8df8fa
Reviewed-on: https://chromium-review.googlesource.com/517162
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45565}

Allow inlining of getters and setters into TurboFan optimized code.
This just adds the basic machinery required to essentially inline
the setter and getter dispatch code for the (keyed) load/store ICs.
There'll be follow up CLs to also actually inline some of the interesting
accessor functions itself, like the byteLength and friends for the
TypedArrays.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2198473002
Cr-Commit-Position: refs/heads/master@{#38192}

In case when F was called with incompatible number of arguments (and therefore
the arguments adator frame was created), F inlines a tail call of G which then
deopts the deoptimizer should also remove the arguments adaptor frame for F.

This CL adds required machinery to the deoptimizer.

BUG=v8:4698
LOG=N

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

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

This reducer doesn't really add value, because:

 (a) it is only concerned with JSCallFunction and JSToNumber, but when
     we get to it, all JSCallFunction nodes will have been replaced by
     Call nodes, and in the not so far future, we will also have
     replaced almost all JSToNumber nodes with better code,
 (b) and the reducer tries to be smart and use one of the outermost
     contexts, but that might not be beneficial always; actually it
     might even create longer live ranges and lead to more spilling
     in some cases.

But most importantly, the JSContextRelaxation currently blocks inlining
based on SharedFunctionInfo, because it requires the inliner to check
the native context, which in turn requires JSFunction knowledge. So I'm
removing this reducer for now to unblock the more important inliner
changes.

R=jarin@chromium.org

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

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

Adds FrameState nodes to graphs built by the Bytecode Graph Builder, in
preparation for adding deopt support. Also adds a new
FrameStateType::kInterpretedFunction to allow for specialized deopt
stack translation for interpreted frames. Finally adds support for
disabling typed lowering of binary ops, since the current approach
relies on a FrameState hack which does not apply to interpreted frames

BUG=v8:4280
LOG=N

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

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

This implements a first version of support for constructor call inlining
in the inlining machinery. For now we can only inline calls where the
actual constructor and the original constructor coincide (i.e. no super
constructor calls). Note that the target of a super constructor call is
loaded with a runtime call, so there is no way for it to be constant
promoted at the moment.

R=bmeurer@chromium.org
BUG=v8:4544
LOG=n

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

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

This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.

Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.

R=bmeurer@chromium.org

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

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

In many cases, the context that TurboFan's ASTGraphBuilder or subsequent
reduction operations attaches to nodes does not need to be that exact
context, but rather only needs to be one with the same native context,
because it is used internally only to fetch the native context, e.g. for
creating and throwing exceptions.

This reducer recognizes common cases where the context that is specified
for a node can be relaxed to a canonical, less specific one. This
relaxed context can either be the enclosing function's context or a specific
Module or Script context that is explicitly created within the function.

This optimization is especially important for TurboFan-generated code stubs
which use context specialization and inlining to generate optimal code.
Without context relaxation, many extraneous moves are generated to pass
exactly the right context to internal functions like ToNumber and
AllocateHeapNumber, which only need the native context. By turning context
relaxation on, these moves disappear because all these common internal
context uses are unified to the context passed into the stub function, which
is typically already in the correct context register and remains there for
short stubs. It also eliminates the explicit use of a specialized context
constant in the code stub in these cases, which could cause memory leaks.

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

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

This also threads through the parameter count and local count to the instruction selector. This will be later used to allow merging of various StateValues vector (and prepare for differential encoding which will not distinguish between parameters, locals and expression stack).

BUG=

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

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

We need the shared function info of inlined functions to prevent code
flushing for their unoptimized code, and also to make sure that liveedit
can find the proper functions to deoptimize.

R=jarin@chromium.org

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

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

R=jarin@chromium.org

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

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

First step towards support for inlining based on SharedFunctionInfo
instead of JSFunction.

R=jarin@chromium.org

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

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

R=jarin@chromium.org
BUG=

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

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