This will give us a baseline for upcoming perf work.

BUG=v8:5940

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

BUG=v8:5516
R=vogelheim@chromium.org

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

Revert of [regexp] Add stub for RegExpExec instead of inlining (patchset #1 id:1 of https://codereview.chromium.org/2677073004/ )

Reason for revert:
Doesn't fix perf regressions in crbug.com/688972 and introduces new ones for RegExp in crbug.com/689395.

Original issue's description:
> [regexp] Add stub for RegExpExec instead of inlining
>
> The code produced for RegExpExec is quite large, and we ended up completely
> inlining it several spots.  This CL moves RegExpPrototypeExecBody into two
> stubs (one each for fast and slow paths) and converts inlined uses into stub
> calls. This decreases the local x64 snapshot size by around 80K.
>
> BUG=chromium:688972
>
> Review-Url: https://codereview.chromium.org/2677073004
> Cr-Commit-Position: refs/heads/master@{#42965}
> Committed: https://chromium.googlesource.com/v8/v8/+/5ea144afe3fd98896fc097a3523de9ab0cb8cd61

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

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

For x64, ia32 and x87 we would pop the return address before the stack
overflow check. This meant the stack couldn't be unwound properly if
it was going to overflow. This CL moves the pop of the return address
to after the stack overflow check.

Also adds a regression test to check that a RangeError is thrown.

BUG=689016

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

BUG=v8:5516
R=vogelheim@chromium.org

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

BUG=v8:5917

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

This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.

Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.

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

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

A script like "{ function foo() {} }" declares a VAR-variable at the
top-level and a LET-variable inside the block.  The LET-variable does
not need to be unconditionally marked as assigned.

BUG=v8:5636

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ed0758e..7968040

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/1e91982..df67b47

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: I80660e6eca542bfe76d5f78656c38583829eab90
Reviewed-on: https://chromium-review.googlesource.com/438964Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42979}

- entries preview available even if debugger agent is disabled,
- less deprecated mirrors usage in debugger-script.js
- no usage of debugger context - zero probability of leaking it.
- better test coverage.

BUG=v8:5510
R=yangguo@chromium.org,jgruber@chromium.org,alph@chromium.org,luoe@chromium.org

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

Adding a code path for strings introduces Phi nodes on the fast
(i.e. non-string) path, causing a performance regression.

BUG=chromium:687075

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

R=adamk

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

- Removes shared InnerArrayCopyWithin JS builtin from src/js/array.js
- Implements %TypedArray%.prototype.copyWithin as a C++ builtin, which
relies on std::memmove rather than accessing individual eleements.
- Fixes the case where copyWithin is invoked on a TypedArray with a
detached buffer.
- Add tests to ensure that +/-Infinity (for all 3 parameters) is handled correctly by the
algorithm

The C++ version gets through the benchmark more than 25000 times as
quickly as the JS implementation.

BUG=v8:5925, v8:5929, v8:4648
R=cbruni@chromium.org, adamk@chromium.org, littledan@chromium.org

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

Embedders should use the new EmbedderHeapTracer api.

BUG=v8:5828

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

The non-determinism of NaNs does not only affect the result of the test
function, it also affects the traps that are thrown.

R=titzer@chromium.org, eholk@chromium.org
BUG=v8:5924

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

Revert of PPC/s390: [debugger] remove debugger statement support from FCG/CS. (patchset #1 id:1 of https://codereview.chromium.org/2672813002/ )

Reason for revert:
Original CL got reverted https://codereview.chromium.org/2672823007

Original issue's description:
> PPC/s390: [debugger] remove debugger statement support from FCG/CS.
>
> Port eef855a1
>
> R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
>
> Review-Url: https://codereview.chromium.org/2672813002
> Cr-Commit-Position: refs/heads/master@{#42898}
> Committed: https://chromium.googlesource.com/v8/v8/+/f2d2ebcae8f31a7787778c429018156a432662e2

TBR=joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

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

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/3ea8977..1e91982

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Change-Id: I5c635ee102c8e523491285ab96e72278ecbaf5c1
Reviewed-on: https://chromium-review.googlesource.com/437965Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42971}

Spotted by clang static analyzer, these variables are declared outside of
the condition but only used within.

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ab0bc70..ed0758e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/d637de7..3ea8977

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

This adapts the inlining logic to allow for inlining based solely on a
statically known underlying SharedFunctionInfo instead of a concrete
closure of the call target.

In cases where the closure is known, its bound context is constant
promoted just as before. In the new cases where only the SFI for an
entire class of closures is known, we use the dynamic SSA-value of the
bound context.

R=bmeurer@chromium.org
BUG=v8:2206

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

It's supposed to be a JSTypedArray, not a JSGeneratorObject

BUG=
R=littledan@chromium.org, adamk@chromium.org, jgruber@chromium.org

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

Also improve suppression of Math.pow precision.

BUG=chromium:679957
NOTRY=true
TBR=mstarzinger@chromium.org,jarin@chromium.org

Change-Id: I43d0cd6f6f6d0867be9f2337990114c07c716df5
Reviewed-on: https://chromium-review.googlesource.com/438327Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42966}

The code produced for RegExpExec is quite large, and we ended up completely
inlining it several spots.  This CL moves RegExpPrototypeExecBody into two
stubs (one each for fast and slow paths) and converts inlined uses into stub
calls. This decreases the local x64 snapshot size by around 80K.

BUG=chromium:688972

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

Keep the order in CHECK_EQ calls consistent as
(expected, actual).

Simplify CHECK_EQ(true, expected) to CHECK(expected) and
CHECK_EQ(false, expected) to CHECK(!expected).

BUG=

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

BUG=v8:5294
R=mstarzinger@chromium.org

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

BUG=chromium:673308

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

The results are unreliable as-is, because es5 and es6 run in the same d8
process consecutively. The graph also shows a huge amount of noise,
which seems to be mostly resolved with this change.

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

In preparation for more perf work in turbofan, so that we can actually
see the results on the graph.

BUG=v8:5932

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

BUG=v8:5668
R=verwaest@chromium.org

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

... by using KeyedStoreIC_Slow builtin instead. The issue with hard-coded
language mode is that the stub can be re-used through megamorphic stub cache for
an IC with incompatible language mode. KeyedStoreIC_Slow already does the
right thing - it decodes the language mode from the IC slot kind.

This CL also fixes the code kinds of the slow IC handlers. The code kind of
IC handlers is used only for checking that the handler was added to the right
megamorphic stub cache, which expect the handlers' code kinds to be either
Code::LOAD_IC or Code::STORE_IC.

And the megamorphic builtins are just helper code stubs that are called from
IC dispatchers, therefore they should have BUILTIN code kind. Same applies to
the other stubs which are neither IC dispatchers nor handlers.

BUG=v8:5917

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

BUG=v8:5516
R=vogelheim@chromium.org

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

BUG=chromium:662424
NOTRY=true
TBR=mstarzinger@chromium.org,jarin@chromium.org

Change-Id: I3576f90a864831e22d065af6ff6ab6b0e2264b1d
Reviewed-on: https://chromium-review.googlesource.com/438305Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42956}

We benefit from the optimizing compiler even if the IC state is generic,
so we'd better ignore the generic IC state count for the optimization
decision. This improves our speedometer score from 61.5 to 63.7
(default configuration is 65.9).

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

BUG=v8:5922

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

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}

BUG=v8:5193
NOTRY=true
TBR=alph@chromium.org,yangguo@chromium.org

Change-Id: I9740f4504c855d9526c7b6b446965996f7c50c0c
Reviewed-on: https://chromium-review.googlesource.com/438344
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42952}

This CL also removes unused LoadApiGetterStub and renames StoreElementStub to StoreSlowElementStub.

BUG=v8:4587

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

TailCallRuntime currently does not seem to handle adaptor frames
correctly.

BUG=chromium:688690

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

BUG=v8:5917

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

NOTRY=true
R=ishell@chromium.org

Change-Id: I99dc19f9904b24ba491334e76adb9486697e8a12
Reviewed-on: https://chromium-review.googlesource.com/438324Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42948}