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}

- Remove TODO concerning maybe-assigned. For LOOKUP variables, the flag
  doesn't really matter, so let's just set it to true to avoid confusion.

- Simplify a condition.

R=adamk@chromium.org
BUG=

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

R=franzih@chromium.org
NOTRY=true

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

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

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

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

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

Add a simple microbenchmark for calling copyWithin on a moderately large
Float64Array with 10,000 elements.

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

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

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/5e0a1c8..bffe083

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

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

Revert of [debugger] remove debugger statement support from FCG/CS. (patchset #5 id:80001 of https://codereview.chromium.org/2650193002/ )

Reason for revert:
Fails on chromium leak bot:
https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Linux%20Trusty%20Leak/builds/2007

Original issue's description:
> [debugger] remove debugger statement support from FCG/CS.
>
>
> R=mstarzinger@chromium.org
>
> Review-Url: https://codereview.chromium.org/2650193002
> Cr-Commit-Position: refs/heads/master@{#42892}
> Committed: https://chromium.googlesource.com/v8/v8/+/eef855a1dc956e9db03ec09abca1d732d379861b

TBR=mstarzinger@chromium.org,yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.

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

The property details of a LookupIterator are not accessible,
if the iterator state is interceptor. Instead, use the
property attributes.

Fixes a crash in Node.js tests in Debug mode, see
https://github.com/nodejs/node/commit/c2c6ae52eaf302da9c106699b69d17c083ced316

BUG=

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d4321a9..629b322

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/53604dd..5e0a1c8

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/88069f4..426ef62

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

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

Blink uses access checks to be sure that objects from one context doesn't access objects in another. Heap profiler uses current context to call this checks, we need to be sure that current context is empty to allow heap profiler collect all objects without crash.

BUG=chromium:661223
R=alph@chromium.org,ulan@chromium.org

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

BUG=687196
R=jbroman@chromium.org

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

BUG=686338
R=cbruni@chromium.org,jbroman@chromium.org

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

This is needed to insulate generated code from blink::protocol namespace
from naming changes that we plan to do in the Great Blink Rename (which
in particular will rename wtf::StringBuilder::find method into Find).

This CL also includes roll of inspector_protocol which starts to
generate code that uses the new StringUtil::find adapter method:
rolling third_party/inspector to 1a7cbe8ba8fa0d622586f549a97c73d9b52efbea

BUG=683447

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

BUG=v8:1569
R=dgozman@chromium.org,alph@chromium.org

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

The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
branch based on whether the accumulator is true or false (no other
value allowed, and in fact TurboFan would blow up if you would pass
anything else, since Branch operator can only deal with Boolean).
So for either branch we know exactly the value of the accumulator,
and we can update the environment to this constant value instead.

This helps to avoid the useless bit materialization that currently
happens when || or && is being used in a value context.

CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win64_dbg
R=jarin@chromium.org
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2666283002
Cr-Original-Commit-Position: refs/heads/master@{#42843}
Committed: https://chromium.googlesource.com/v8/v8/+/158ac9287193f315342ad31c38fe451620d176eb
Review-Url: https://codereview.chromium.org/2666283002
Cr-Commit-Position: refs/heads/master@{#42934}