This CL introduces a ProtectedLoad instruction with is needed for out
of bounds trap handling. ProtectedLoad behaves like a regular load,
but it takes a context and source position parameter as well. These
are used by an out of line code fragment to generate code to throw a
JS exception for an out of bounds memory reference in Wasm.

These changes a cleaned up subset of
https://codereview.chromium.org/2148743004/

The rest of this feature will follow in future CLs. This includes a
table mapping memory instructions to landing pads as well as the
actual signal handler.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

The array spread operator is now handled by desugaring in the parser.

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

R=nikolaos@chromium.org

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

Migrate the platform ToName stub to TurboFan.

BUG=v8:5049

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

BUG=chromium:635948

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

GetFunctionNameStr and GetScriptResourceNameStr can be called from a thread
other than isolate VM thread unlike their conterparts GetFunctionName
and GetScriptResourceName.

BUG=406277

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

Rolling v8/build to 69b6a57635907f95b6302a657d250832e3f91a1f

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to bfc71ffbbdc7ca43723d655d8d4ae972e9e431da

Rolling v8/third_party/jinja2 to b61a2c009a579593a259c1b300e0ad02bf48fd78

Rolling v8/tools/clang to 7d0756c437d8c3dd68f912f6cc47907b0120fc05

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

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

This will be synced with an announcement on v8-dev. This
doesn't affect directly calling gyp in our old Makefiles.

BUG=chromium:474921
NOTRY=true

Committed: https://crrev.com/94f813e8dcd4ed5a67cede8af0f949009beaa501
Review-Url: https://codereview.chromium.org/2327033002
Cr-Original-Commit-Position: refs/heads/master@{#39308}
Cr-Commit-Position: refs/heads/master@{#39311}

BUG=v8:5260

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

Revert of [gn] Switch off gyp in runhooks by default (patchset #2 id:20001 of https://codereview.chromium.org/2327033002/ )

Reason for revert:
Broke stuff - need to fix the argument

Original issue's description:
> [gn] Switch off gyp in runhooks by default
>
> This will be synced with an announcement on v8-dev. This
> doesn't affect directly calling gyp in our old Makefiles.
>
> BUG=chromium:474921
> NOTRY=true
>
> Committed: https://crrev.com/94f813e8dcd4ed5a67cede8af0f949009beaa501
> Cr-Commit-Position: refs/heads/master@{#39308}

TBR=jochen@chromium.org,jkummerow@chromium.org,vogelheim@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:474921

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

This will be synced with an announcement on v8-dev. This
doesn't affect directly calling gyp in our old Makefiles.

BUG=chromium:474921
NOTRY=true

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

... and rename CheckAndGrowElementsCapacity() to TryGrowElementsCapacity().

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

This fixes a corner-case where the bytecode was using the <new.target>
register directly without going through the local variable. The value
might be clobbered because the deoptimizer doesn't properly restore the
value. The label will causes bytecode pipeline to be flushed and hence
ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.

R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-645103
BUG=chromium:645103

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

Revert of [heap] Fix a formatting bug in --trace-incremental-marking. (patchset #2 id:20001 of https://codereview.chromium.org/2324623004/ )

Reason for revert:
Revert to check if this is causing perf regressions in crbug.com/645411

Original issue's description:
> [heap] Fix a formatting bug in --trace-incremental-marking.
>
> BUG=
>
> Committed: https://crrev.com/212624b7570cd1c1cfad7cf958203b05af961637
> Cr-Commit-Position: refs/heads/master@{#39278}

TBR=mlippautz@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/2323293002
Cr-Commit-Position: refs/heads/master@{#39305}

TBR=bmeurer@chromium.org
BUG=v8:5294

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

BUG=chromium:474921
NOTRY=true
TBR=jochen@chromium.org

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

For call sites where the target is not a known constant, but potentially
a list of known constants (i.e. a Phi with all HeapConstant inputs), we
still record the call site as a potential candidate for inlining.
In case the heuristic picks that candidate for inlining, we
expand the call site to a dispatched call site and invoke the
actual inlining logic for all the nested call sites.

Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining,
although we might want to refine that later.

This approach is different from what Crankshaft does in
that we don't duplicate the evaluation of the parameters per polymorphic
case. Instead we first perform the load of the target (which usually
dispatches based on the receiver map), then we evaluate all the
parameters, and then we dispatch again based on the known targets. This
might generate better or worse code compared to what Crankshaft does,
and for the cases where we generate worse code (i.e. because we have
only trivial parameters or no parameters at all), we might want to
investigate optimizing away the double dispatch in the
future.

R=mvstanton@chromium.org
BUG=v8:5267,v8:5365

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

This is a work-around as v8_enable_i18n_support=false does
currently not imply icu_use_data_file_flag=false. The
swarming isolator then tries to find the data file also
in builds without ICU.

Making the implication is non-trivial as icu_use_data_file_flag lives
in ICU and v8_enable_i18n_support lives in V8.

BUG=chromium:474921
NOTRY=true
TBR=petermarshall@chromium.org, vogelheim@chromium.org, jochen@chromium.org

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

BUG=

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

  port 9a31162d(r39283)

  original commit message:
  Adds support to collect allocation site feedback for Array function calls
  to the call bytecode handler.

BUG=

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

Port 9a31162d

Original commit message:

    Adds support to collect allocation site feedback for Array function calls
    to the call bytecode handler.

R=mythria@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

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

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

BUG=

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

Without this cast, the integer type isn't promoted before being shifted, and so
for types larger than sizeof(int) there is data loss. This will become an issue
once the host begins using this helper to send 64-bit integers.

BUG=chromium:148757

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

This patch adds runtime call stats tracing for GC correctly, makes
--runtime-call-stats and tracing mutually exclusive with tracing taking
precedence if both modes are on, and uses only one runtime call stats in
counter.

BUG=v8:5089

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

Before this change, the spread desugaring would naively call
`%AppendElement($R, the_hole)` and in some cases $R would have
a non-holey elements kind, putting the array into the bad state
of exposing holes to author code.

This patch avoids calling %AppendElement with a hole, instead
simply incrementing $R.length when it sees a hole in the literal
(this is safe because $R is known to be an Array). The existing
logic for elements transitions takes care of giving the array a
holey ElementsKind.

BUG=chromium:644215

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

This CL fixes %DebugPrint for FAST_HOLEY_DOUBLE_ELEMENTS and now properly
distinguishes TheHole and NaN values.

BUG=

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

Revert of [runtime] temporarily transform IsContext check from DHECK to CHECK (patchset #2 id:20001 of https://codereview.chromium.org/2164633002/ )

Reason for revert:
There have been no more occurrences of this on dev / beta so we can convert the CHECK back to DCHECK.

Original issue's description:
> [runtime] temporarily transform IsContext check from DCHECK to CHECK
>
> We are enabling this trial on canary to see if we can flush out some missing
> context restores.
>
> BUG=
>
> Committed: https://crrev.com/ec94ad400dc257af396efa3b1899bc3168347d82
> Cr-Commit-Position: refs/heads/master@{#37875}

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

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

BUG=v8:5363
R=adamk@chromium.org, littledan@chromium.org, cbruni@chromium.org

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

The previous DCHECK (removed in issue 2316033002) was checking that the new interval strictly overlapped with the first interval.

BUG=

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

Drive-by-fix: the old code never triggered write barrier.
Review-Url: https://codereview.chromium.org/2321993002
Cr-Commit-Position: refs/heads/master@{#39289}

BUG=v8:4124
TEST:test-run-wasm-simd
R=titzer@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org

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

Revert of Use -fno-delete-null-pointer-checks with gcc builds (patchset #2 id:20001 of https://codereview.chromium.org/2310513002/ )

Reason for revert:
Fails on MIPS: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/3653

Original issue's description:
> Use -fno-delete-null-pointer-checks with gcc builds
>
> R=bmeurer@chromium.org, jochen@chromium.org, machenbach@chromium.org
> BUG=v8:3782
>
> Committed: https://crrev.com/dbefc8ee2e9ee6e41b83f3d09c788c34bc923b43
> Cr-Commit-Position: refs/heads/master@{#39286}

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

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

R=bmeurer@chromium.org, jochen@chromium.org, machenbach@chromium.org
BUG=v8:3782

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

Fell through the cracks in a recent CL. Should have switched
with the CI bot, which is on GN already.

BUG=chromium:474921
NOTRY=true

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

BUG=
R=ulan@chromium.org

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

Adds support to collect allocation site feedback for Array function calls
to the call bytecode handler.

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

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

I could not reproduce the bug in either a unittest nor a cctest. That's
why I created an mjsunit test now.

BUG=chromium:644682
R=titzer@chromium.org

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

BUG=chromium:644643
NOTRY=true

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

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

The existing PropertyQueryCallback intercepts getOwnPropertyDescriptor, but
it returns only value and attributes, not the accessors. This
PropertyDescriptorCallback returns a descriptor similar to Ecma-262 6.2.4.

You can either set a PropertyQueryCallback or a PropertyDescriptorCallback,
but not both. When you set a callback for DefineProperty(), you can set a
PropertyDescriptorCallback but not a PropertyQueryCallback.

BUG=v8:5359

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