Use an opaque format for the frame type marker on the stack, where the
marker is simply shifted left by 1 instead of being a Smi. This allows
us to generate simpler code for frame initialisation, as we can push a
smaller value, decreasing the prologue by 4 bytes and one instruction.

Drive-by: Use the same format for JsFrameMarker.

Change-Id: I812dde9b37869fe20de4148a665d06cf23ce7372
Reviewed-on: https://chromium-review.googlesource.com/443426Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43347}

The mips64 implementation always ended up in the slowpath due to some
loads that were the wrong width, so that is also fixed here.

BUG=v8:5974

Change-Id: Ie448a1fab5b7fca87597c5a1bf75443864e30c28
Reviewed-on: https://chromium-review.googlesource.com/443247
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43222}

If the Reflect.construct receives an argument expected to be a constructor,
and the argument is not a constructor, V8 currently declares that
Reflect.construct is not a function. It should instead say that the offending
argument is not a constructor.

This is the case for all ports of builtins
(Builtins::Generate_ReflectConstruct). All of them make an
attempt to at least pass the right argument to the TypeError parametrised
message, calling out the offending Reflect.construct argument. However,
Runtime::kThrowCalledNonCallable extracts the callsite from those arguments,
discarding the precise information.

This CL adds Runtime::kNotConstructor, which reports the arguments passed
to it, and the CL also modifies the ports of builtins to make use of
Runtime::kNotConstructor

BUG=v8:5671

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

This adds support for deoptimizing into the JSConstructStub after the
receiver instantiation but before the actual constructor invocation.
Such a deoptimization point is needed for cases where instantiation
might be observed (e.g. when new.target is a proxy) and hence might
trigger a deopt.

We use this new deoptimization point for the "after" frame-state the
inliner attaches to {JSCreate} nodes being inserted when constructor
calls are being inlined.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-5638b
BUG=v8:5638

Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
Reviewed-on: https://chromium-review.googlesource.com/440125Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43149}

... and TypeFeedbackMetadata to FeedbackMetadata.

BUG=

Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}

TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.

Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.

Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.

This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.

BUG=v8:5456

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

They have the same lifetime. It's a match!

Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.

A follow-on CL removes even more parser infrastructure related to this count.

BUG=v8:5456

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

We need it to be a PropertyCell so that we can list it as a dependency for
optimised code.

Also drive-by clean up some variable names in src/isolate-inl.h.

BUG=v8:5895

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

We turn a JSCallFunction node for

  f.apply(receiver, arguments)

into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.

We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.

R=jarin@chromium.org
BUG=v8:5267,v8:5726

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

We did not smi-check the spread argument here, meaning we tried to take the map
of a smi, resulting in segfaults which clusterfuzz found.

Also added tests that exercise this path.

BUG=685086

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

We can share almost all of the architecture-specific builtin code with super-call-with-spread.

Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.

BUG=v8:5511

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

We are planning to add a few more debugger related bits, and are running
out of compiler hints bits. The new bit field is going to be part of the
debug info struct. If the debug info is not available, we store the bit
field in its place on the shared function info.

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

FAST_DOUBLE_ELEMENTS and FAST_HOLEY_DOUBLE_ELEMENTS kinds should both
be handled by the runtime.

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

GC performance issues need to be addressed first.

TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:5456

Review-Url: https://codereview.chromium.org/2642743002
Cr-Original-Commit-Position: refs/heads/master@{#42495}
Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567
Review-Url: https://codereview.chromium.org/2642743002
Cr-Commit-Position: refs/heads/master@{#42517}

Revert of Revert [TypeFeedbackVector] Root literal arrays in function literal slots (patchset #2 id:20001 of https://codereview.chromium.org/2642743002/ )

Reason for revert:
Breaks nosnap:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/13802

Original issue's description:
> Revert [TypeFeedbackVector] Root literal arrays in function literal slots
>
> GC performance issues need to be addressed first.
>
> TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2642743002
> Cr-Commit-Position: refs/heads/master@{#42495}
> Committed: https://chromium.googlesource.com/v8/v8/+/7803aa1ffb2f835c5f317ed2a097390d53e52567

TBR=mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456

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

GC performance issues need to be addressed first.

TBR=bmeurer@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:5456

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

Due to outstanding performance issues, it's safer to revert these
changes.

Revert "PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "[TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "PPC/s390: [builtins] CompileLazy bailed out to the runtime entirely too often."
Revert "[builtins] CompileLazy bailed out to the runtime entirely too often."

Another CL is to follow that removes the main part of this work
(after that revert, performance regressions should disappear.

TBR=mstarzinger@chromium.org, leszeks@chromium.org, bmeurer@chromium.org
BUG=680637

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

BUG=v8:5659

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

There were multiple bugs in the apply builtins on mips and mips64 which
caused them to always take the slow path by calling into the runtime to
create the array. The other bugs went undiscovered because those paths
were never taken.

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

This is just a bug. CompileLazy knows how to look in the
SharedFunctionInfo for code (or bytecode, essentially) if it
finds nothing in the OptimizedCodeMap. Ensure that behavior.

BUG=681543
R=leszeks@chromium.org

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

The resume trampolin used to call the generator function with the context of the
last suspension rather than the closure's context.  While that was fine for
Ignition, Turbofan got utterly confused.  With this CL, the resume trampolin
always passes in the closure's context (like in the very first call of the
generator function).  The generator function itself then restores its previously
current context by reading it from the generator object and doing a
PushContext.

BUG=chromium:681171

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

R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5821

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

Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2620753003
Cr-Original-Commit-Position: refs/heads/master@{#42258}
Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6
Review-Url: https://codereview.chromium.org/2620753003
Cr-Commit-Position: refs/heads/master@{#42264}

Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #7 id:120001 of https://codereview.chromium.org/2620753003/ )

Reason for revert:
gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/8105

also on mac

Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2620753003
> Cr-Commit-Position: refs/heads/master@{#42258}
> Committed: https://chromium.googlesource.com/v8/v8/+/31887804107bf5c103d915f5c601cfaaf1cd7cb6

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

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

Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

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

Currently the CompileLazy builtin checks the SFI expliciltly for FCG code. This means
if the SFI has bytecode we have to go through to the runtime to install the
interpreter entry trampoline into the JSFunction object.

Modify the builtin to always put the SFI code object into the JSFunction unless it's
the lazy compile stub on the SFI as well.

BUG=v8:4380

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

In the process, convert from a code stub into a builtin.

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

Revert of [TypeFeedbackVector] Root literal arrays in function literals slots (patchset #11 id:370001 of https://codereview.chromium.org/2504153002/ )

Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/

Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: https://chromium.googlesource.com/v8/v8/+/93df094081f04c629c3df2e40318de90ce5e0fb9

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

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

Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.

To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.

BUG=v8:5456

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

The patch was reverted due to a bug - we failed to evict OSR-optimized
code in the case where the SharedFunctionInfo OptimizedCodeMap was
empty/cleared.

Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.

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

Revert of Store OSR'd optimized code on the native context. (patchset #8 id:140001 of https://codereview.chromium.org/2549753002/ )

Reason for revert:
Speculative revert WebGL breakage reported in https://bugs.chromium.org/p/chromium/issues/detail?id=672367

Original issue's description:
> Store OSR'd optimized code on the native context.
>
> Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
>
> BUG=
>
> Committed: https://crrev.com/378b6b22fb7925ac5b672335a54599f5739e7758
> Cr-Commit-Position: refs/heads/master@{#41554}

TBR=mstarzinger@chromium.org, mvstanton@chromium.org, ulan@chromium.org
BUG=

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

Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.

BUG=

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

Port for 3396bb29

TEST=
BUG=

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

Port of d4f01b8a

BUG=

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

Adds a bytecode_age field to BytecodeArray objects. This is incremented each
time the bytecode array is marked by GC, and reset to zero if the bytecode
is executed.

This is used to enable the CompilationCache for interpreted functions,
where Interpreted entries are evicted once the bytecode becomes old.

BUG=chromium:666275,v8:4680

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

MarkingParity was used to avoid performing an operation on an object if it was
marked multiple times. We no longer mark things multiple times, so this concept
is no longer required.

BUG=chromium:666275

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

This removes the deprecated generator support for resumable functions
from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
triggers Ignition for most resumable functions, with this change we make
said heuristic a hard choice and remove the deprecated code. This also
has the advantage that any suspended {JSGeneratorObject} instance on the
heap is guaranteed to have code based on a bytecode array.

R=bmeurer@chromium.org

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

This changes {FrameState} nodes modeling "after" states to use bytecode
offsets pointing to the deoptimizing bytecode. This is in sync with the
normal execution, as the bytecode offset is advanced after operations
complete in regular bytecode handlers.

The change is necessary to ensure lazy deoptimized frames contain an
accurate bytecode offset while they are on the stack. Such frames can be
inspected by various stack walks. The continuation builtin will advance
the bytecode offset upon return.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-660379
BUG=chromium:660379

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

This removes the deprecated flag in question which has been enabled by
default a while ago. All components can by now deal with activations of
a single function being mixed between Ignition and other compilers. The
maintenance overhead to support a mode that clears bytecode is no longer
warranted.

R=rmcilroy@chromium.org
BUG=v8:4280

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

Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.

BUG=v8:5512

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