port 46648402 https://crrev.com/c/1871605

Original Commit Message:

CallDebugOnFunctionCall was always using Registers and not Immediates.
    Then ParameterCount is not really needed. Since updating that, we
    could update other functions, e.g InvokeFunction, to only use
    registers too.

    Also removed now irrelevant variables, e.g definitely_mismatches.

[mips][codegen] Removed ParameterCount class

port 1e696896 https://crrev.com/c/1886916

Original Commit Message:

    It was used only with Register inputs, so we can replace its uses with
    the Registers themselves.

Change-Id: I0a661519f5602bf4d52c40c6c238436b93b71664
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898826Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64753}

These are two of the remaining missing instructions from the MVP.
This CL adds support to {LiftoffCompiler} and provides assembly
implementations for ia32, x64, arm, and arm64.

R=jkummerow@chromium.org

Bug: v8:9919
Change-Id: I4d00d2030e1c5c03ee3afaa536697d3847e26ef0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893343
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64752}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/55891eb..3a13923

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5321943..70d4ef3

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/79d9e4b..f6a2232

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: Ie99e8f1c2351383b6482e38b428a48deba15c719
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898745Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#64751}

Bug: v8:9810
Change-Id: If24af27716f4fb5a6e5ae077afa9719fc5e85795
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895705Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64750}

This reverts commit d4574d18.

Reason for revert: In addition to the earlier octane regression, this cl also created a regression in desktop browsing

Bug: chromium:1019601

Original change's description:
> Reland "[regexp] Clone match info for match indices."
> 
> This reverts commit d7793c06.
> 
> Reason for revert: This cl *will* cause regexp regressions. We are trying to gauge the real world impact.
> 
> Original change's description:
> > Revert "[regexp] Clone match info for match indices."
> >
> > This reverts commit dfd9ceb9.
> >
> > Reason for revert: Regressions https://chromeperf.appspot.com/group_report?rev=64356 https://crbug.com/1015749
> >
> > Original change's description:
> > > [regexp] Clone match info for match indices.
> > >
> > > The current behavior for generating match indices simply stashes a
> > > pointer to the match info and then constructs the indices lazily.
> > > However, it turns out the match info object used to create the result
> > > object is the regexp_last_match_info living on native context, and thus
> > > it can change between the creation of the result object and the generation
> > > of indices. This cl clones the match info which will be safer.
> > >
> > > Bug: v8:9548
> > > Change-Id: Ia6f26f88fbc22fd09671bf4c579d39a1510b552d
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864585
> > > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#64356}
> >
> > TBR=jgruber@chromium.org,joshualitt@chromium.org
> >
> > # Not skipping CQ checks because original CL landed > 1 day ago.
> >
> > Bug: v8:9548, chromium:1015749
> > Change-Id: I9c30b8fb459cf2aa89d920bf061614441250844d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1870236
> > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64407}
> 
> TBR=jgruber@chromium.org,joshualitt@chromium.org
> 
> 
> Bug: v8:9548, chromium:1015749
> Change-Id: I151511307e3d8752fdbde4b8247514031b141b08
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879587
> Reviewed-by: Joshua Litt <joshualitt@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64587}

TBR=jgruber@chromium.org,joshualitt@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:9548, chromium:1015749
Change-Id: Ie5a8e55338728aae33102d82e60a188f6440e8f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898030Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64749}

This reverts commit 54379af9.

Reason for revert: Big performance regressions, need to investigate

Original change's description:
> [wasm] Remove fixed limit on number of background tasks
> 
> After fixing https://crbug.com/v8/8916, background compilation scales
> far beyond 10 threads, especially for TurboFan (where much more work is
> parallelizable). Thus, remove the limit of 10 background compilation
> tasks, and use all available threads instead.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:8916
> Change-Id: I13c30777e3c85b2de7901b5eac3e6a41457a56f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893348
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64724}

TBR=mstarzinger@chromium.org,clemensb@chromium.org

Change-Id: I180cff9f39d8960aa793f279cfb61b7444992bc6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897889Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64748}

Bug: v8:6949
Change-Id: If147de926cdc0b03f1bba17974edfce21d7fb256
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897887Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64747}

Before this change large fixed arrays were visited in chunks of 32KB
on the main thread. Now large fixed arrays are divided into chunks
of kMaxRegularHeapObjectSize, which is consistent with large fixed
array processing on concurrent threads and make more sense considering
that regular fixed arrays are visited in one go.

Bug: chromium:1019218
Change-Id: I0c6d9c6c7d1db7f6a75d282601b73d4819b30e80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897886Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64746}

This makes WebAssembly runtime stubs use Smi encoding for parameters in
instead of a HeapNumber encoding whenever possible. This potentially
avoids allocating on the GC'ed heap.

R=clemensb@chromium.org

Change-Id: Ie37c3005442748d9bd71da59a2c11d103a65fe9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895574
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64745}

Change builtin calls in wasm-compiler.cc to use CallBuiltinPointer
rather than CallCodeObject which means they bypass the trampoline.

Since the Code objects are no longer being called, remove them from the
executable Code object allow-list in builtins.cc.

Bug: v8:9338
Change-Id: I9835bab859c4d5e45dbfb4c7a339ccf74e719237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893337
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64744}

This makes the stop-the-world marking visitor the same as incremental
visitor for processing large fixed arrays.

Bug: chromium:1020982
Change-Id: Ie3b4ea7ad397ea0ae00000875aca0d142f672a3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897828Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64743}

We'll remove the file from Chromium in a follow up after V8 has rolled
+ 2 days.

Bug: v8:9911
Change-Id: I69fe56855f1ba83bec0d39e0fb6acb7e4182c6b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897826Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64742}

Port 352bbb12

Original Commit Message:

    This is a reland of 855591a5

    Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
    Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.

    Original change's description:
    > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
    >
    > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
    >
    > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
    >
    > Creates an allow-list of builtins that can still go in code_space
    > including all TFJ builtins and a small manual list that should be pared
    > down in the future.
    >
    > For builtins that go in RO_SPACE a Code object is created that contains an
    > immediate trap instruction. Generally these Code objects are still no
    > smaller than CODE_SPACE Code objects because of the Code object alignment
    > requirements. This will hopefully be addressed in a follow-up CL either by
    > relaxing them or removing the instruction stream completely.
    >
    > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
    > increases by the same amount.
    >
    > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
    > Commit-Queue: Dan Elphick <delphick@chromium.org>
    > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#64700}

R=delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: If150434119828a87e295b0639c934392812bb345
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1896904Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64741}

Now that embedded builtins are mandatory and non-embedded builtins no
longer need to be supported, it is safe to embed the target of the
CEntry builtin directly into the {WasmCompileLazy} builtin. This just
uses the regular {MacroAssembler::CallRuntime} functionality now.

R=clemensb@chromium.org

Change-Id: Id09e73e96cc43fe019c837b9cc42df441c6aada0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895571
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64740}

Now that embedded builtins are mandatory and non-embedded builtins no
longer need to be supported, it is safe to embed the target of the
CEntry builtin directly into WebAssembly runtime stubs. This produces
more efficient code and simplifies the runtime stubs.

R=clemensb@chromium.org

Change-Id: If2f91fa733edc266af3a204ac17ff36e4c0b41a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895567
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64739}

This issue was fixed in https://chromium-review.googlesource.com/c/v8/v8/+/1873692

Bug: chromium:1016450
Change-Id: I56e1c504ae6876283568a88a9aa7d24af3ba6474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876057
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64738}

This simplifies how WebAssembly runtime stubs call other builtins.
Instead of loading the {AllocateHeapNumber} builtin from the instance,
we can now embed its direct functionality since builtins are always
independent of the Isolate by now.

R=delphick@chromium.org

Change-Id: Ieb22e9406aa825e84482acc82619a33821a43758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895565Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64737}

There seems to be a bug in Python versions prior
to 2.7.9 where running exec could produce the following error:

SyntaxError: unqualified exec is not allowed in function
'_ParsePythonTestTemplates' it contains a nested function
with free variables (testcfg.py, line 71)

https://bugs.python.org/issue21591

It's causing an issue on all Ubuntu 14 and RHEL 7 machines.

The proposed change is an equivalent syntax which doesn't
produce an error:
https://docs.python.org/2/reference/simple_stmts.html#the-exec-statement


Change-Id: I159cc1be58ff375f313ae5c4fb814763704b880e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893647Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#64736}

This CL adds V8_EXPORT_PRIVATE declarations needed for component build with
enabled MSAN on Linux.

Change-Id: Ia79ca117b8f5128f8e681b0574066e86f2407a84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893342Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64735}

Bug: v8:6949
Change-Id: Ie26d89e3219a8ac54b643cc8817a85797000d1e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895557Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64734}

Changing the target of JSCall nodes (e.g. while lowering higher order calls)
now preserves feedback and speculation mode to allow further (speculative)
optimizations. A flag is introduced to mark feedback unrelated to the call
target after such a transformation. This flag is used to prevent access to
the feedback without the need to invalidate it.

Bug: v8:9702
Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64733}

Relevant opcodes:
 * kFrameState
 * kStateValues
 * kTypedStateValues

The code to decompress CompressedHeapConstants is not there for the
opcodes stated above. We can only do this optimization for Loads
for the moment.

Bug: v8:7703
Change-Id: I226089f1b2b78d0bd742785c7c9924284a97c72d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879942
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64732}

... in an uintptr index friendly way.

Bug: v8:8906, v8:4153
Change-Id: Ib06ac205453fe3ff653b4fb73194e1ab53ca0d00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1891610
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64731}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bbcd1e4..55891eb

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1ce01db..5321943

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/540178c..79d9e4b

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: Iaa3f95bf1d06b9cfc824d3145936a7ab2b9db918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893705Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#64730}

Bug: v8:9810
Change-Id: Ie371220afd332322cc3d613f7c84ca254bd5dd78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895556
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64729}

This is a reland of 855591a5

Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.

Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}

Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64728}

Add a new LargeObjectSpace for off-thread allocation. Similar to the
paged OffThreadSpace, it always allocates pages, doesn't participate
in mark or sweep, and can be merged into the OldLargeObjectSpace once
its objects are ready.

Bug: chromium:1011762
Change-Id: I95e2d38b10a9cc5eae4ffd35afef95272e13c731
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881153
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64727}

PR wasn't defined correctly and it was causing issues.

Added prettify to the npm packages, and removed the (not needed)
explicit prettify.css.

Bug: v8:7327
Change-Id: Ieb8999d63df6764354dd628516e0ed9270b8a862
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893344
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64726}

chromium rolling in https://chromium-review.googlesource.com/c/chromium/src/+/1896236

Bug: v8:9741
Change-Id: I64e5cfc9200b59e8c7a908ddd8c46a525d2581c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1896280
Auto-Submit: Frank Tang <ftang@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64725}

After fixing https://crbug.com/v8/8916, background compilation scales
far beyond 10 threads, especially for TurboFan (where much more work is
parallelizable). Thus, remove the limit of 10 background compilation
tasks, and use all available threads instead.

R=mstarzinger@chromium.org

Bug: v8:8916
Change-Id: I13c30777e3c85b2de7901b5eac3e6a41457a56f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893348Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64724}

Moves all of the KeyedSloppyArguments functions out of CodeStubAssembler
and into builtins-handler-gen.cc which is the only place they're used.

Bug: v8:9810
Change-Id: Ie52bdf24b7890943b89007f566dd18fe644a5996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895558Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64723}

This re-enables verification for RO_SPACE when V8_SHARED_RO_HEAP is
defined. This required refactoring PagedSpaceObjectIterator and methods
in its calling chain to explicitly pass the PagedSpace and Heap pointers
through as they cannot be obtained from the Page in this mode.

Also removes unused Page::Print() method.

Bug: v8:7464
Change-Id: Ibc2c147a7bde6723f43bbaf93cf1db93e76c611e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893350Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64722}

This CL improves reporting for WeakMap entries: If a retaining chain
goes through a WeakMap entry (i.e. key and weak map are alive, and keep
value alive) then both the key and the value are reported. Additionally
the phrasing is clarified, such that entries in retaining paths are
easier to understand.

Bug: chromium:1020096
Change-Id: Ib05cd6f7939c6de41b554c682ad1fbf685b87608
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893335Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64721}

Change-Id: I7993bf1d27c0b7a148e776c7c2eddf4ebe76da6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1892951Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64720}

This fixes a compilation error in Node.js with Xcode:

initialize the const member 'blueprint_'.

error: constructor for 'v8::internal::compiler::Callee' must explicitly
Change-Id: Ia55398428d0de35a9ad5132eabd22d0adb694514
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895561
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64719}

Port b875f466

Original Commit Message:

    Reland "[compiler] Optionally apply an offset to stack checks"

    This is a reland of 4a16305b

    The original CL adjust only one part of the stack check, namely the
    comparison of the stack pointer against the stack limit in generated code.
    There is a second part: Runtime::kStackGuard repeats this check to
    distinguish between a stack overflow and an interrupt request.

    This second part in runtime must apply the offset just like in generated
    code. It is implemented in this reland by the StackCheckOffset operator
    and a new StackGuardWithGap runtime function.

    Original change's description:
    > [compiler] Optionally apply an offset to stack checks
    >
    > The motivation behind this change is that the frame size of an optimized
    > function and its unoptimized version may differ, and deoptimization
    > may thus trigger a stack overflow. The solution implemented in this CL
    > is to optionally apply an offset to the stack check s.t. the check
    > becomes 'sp - offset > limit'. The offset is applied to stack checks at
    > function-entry, and is set to the difference between the optimized and
    > unoptimized frame size.
    >
    > A caveat: OSR may not be fully handled by this fix since we've already
    > passed the function-entry stack check. A possible solution would be to
    > *not* skip creation of function-entry stack checks for inlinees.
    >
    > This CL: 1. annotates stack check nodes with the stack check kind, where
    > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
    > allocates a temporary register to store the result of the 'sp - offset'
    > in instruction selection (and switches input registers to 'unique'
    > mode). 3. Applies the offset in code generation.
    >
    > mode). 3. Applies the offset in code generation.
    >
    > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
    >
    > Bug: v8:9534,chromium:1000887
    > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
    > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
    > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
    > Reviewed-by: Georg Neis <neis@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#63701}

Change-Id: I77554bddde57153ec92c4b80c15d0a52efbaab2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893554Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Mu Tao <pamilty@gmail.com>
Cr-Commit-Position: refs/heads/master@{#64718}

Change-Id: I174d38cc33210c07d1a7596627e1b2d21bb06313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895560Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Cr-Commit-Position: refs/heads/master@{#64717}

Currently atomic operations are only allowed on shared WebAssembly.memory.
An attempt to use atomic operations otherwise is a validation failure, there
is an ongoing attempt to allow Wasm atomic operations on any memory object.

https://github.com/WebAssembly/threads/issues/144

This CL adds experimental support for allowing atomic operations on all
memory objects behind the --wasm-atomics-on-non-shared-memory flag. Note
that Wait/Notify may not work as expected as they have additional checks
to ensure that the memory is a SAB.

Bug: v8:9921
Change-Id: Ia65b1a4a96ec026430fcce028465423f600adacd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895703
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64716}

Blink-dev intent to ship thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/TI4h1Gj5TYE

Bug: v8:9553
Change-Id: Icef9e4aeec1e519ab8ce11109e2529c61437a10b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895427
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64715}

This reverts commit b8ac4eb4.

Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1020533

Original change's description:
> [runtime] Correctly handle global stores when global object has proxies
> 
> When global object has proxies we should first call hasProperty and
> then call SetProperty if has property returns true. This cl fixes both
> StoreGlobal and StoreLookupGlobal to correctly handle these cases.
> 
> Bug: chromium:1018871
> Change-Id: I140514e2119c6bab2125abcdc1b19d46526be5ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1889885
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64687}

TBR=mythria@chromium.org,verwaest@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:1018871
Change-Id: I5abbf9275cba17576e1b1e492abd36d6bc1ca1bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893194Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64714}