It's been on by default since Chrome 61.

Bug: v8:4806
Change-Id: I748d9008d29997667458649d7bf4999e15ff8615
Reviewed-on: https://chromium-review.googlesource.com/737416
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48943}

Bug: v8:6791
Change-Id: I9c1ebddfab9f3d73642e61e43c3fbfd739efd56c
Reviewed-on: https://chromium-review.googlesource.com/736722
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48942}

This reverts commit 877de376.

Reason for revert: Looks like this doesn't really move the needle (only w/ high iteration count). So let's not do the extra complexity unless there's a good reason to do so.

Original change's description:
> [turbofan] Introduce FindOrderedHashMapEntryForReceiverKey operator.
> 
> This optimizes Map#get and Map#has for the case where the key is known
> to be a JSReceiver. This generalizes the existing logic for the
> FindOrderedHashMapEntryForSigned32Key operator to also deal with
> receivers. This gives a nice 33% boost on the map-set-lookup-es6 test
> of the six-speed benchmark suite.
> 
> Drive-by-fix: Rename the FindOrderedHashMapEntryForInt32Key operator to
> FindOrderedHashMapEntryForSigned32Key to match the naming of the types.
> 
> R=​jarin@chromium.org
> 
> Bug: v8:5267, v8:7001
> Change-Id: Ifab8414f26adee7ec833d8cb94ae0ac49f2c3d35
> Reviewed-on: https://chromium-review.googlesource.com/738180
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48938}

TBR=jarin@chromium.org,bmeurer@chromium.org

Change-Id: Icaf9e22cb3412a97342c4e4cdc422d4aaa2d0ef9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5267, v8:7001
Reviewed-on: https://chromium-review.googlesource.com/738052Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48941}

For the tagged case, we never use the Literal AST node, so don't bother
creating them in the first place. Instead, store AstRawStrings directly,
and only wrap with Literals when desugaring untagged templates into
binary ops.

This also makes the upcoming merge of Literal and AstValue simpler.

Bug: v8:6984
Change-Id: I9f12710b05c6d63d7e91f2707cd08093f7ff3f11
Reviewed-on: https://chromium-review.googlesource.com/736151Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48940}

Since https://crrev.com/c/712734, this struct is not being used any
more.

R=titzer@chromium.org

Change-Id: I5b7a73e99ef50fa4fd0f05f6e2b97fa54ea19f1d
Reviewed-on: https://chromium-review.googlesource.com/738033Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48939}

This optimizes Map#get and Map#has for the case where the key is known
to be a JSReceiver. This generalizes the existing logic for the
FindOrderedHashMapEntryForSigned32Key operator to also deal with
receivers. This gives a nice 33% boost on the map-set-lookup-es6 test
of the six-speed benchmark suite.

Drive-by-fix: Rename the FindOrderedHashMapEntryForInt32Key operator to
FindOrderedHashMapEntryForSigned32Key to match the naming of the types.

R=jarin@chromium.org

Bug: v8:5267, v8:7001
Change-Id: Ifab8414f26adee7ec833d8cb94ae0ac49f2c3d35
Reviewed-on: https://chromium-review.googlesource.com/738180Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48938}

R=mstarzinger@chromium.org

Change-Id: Ic36d33ff8d1edeefc745146ec1c1203e08181565
Reviewed-on: https://chromium-review.googlesource.com/737992Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48937}

This reverts commit 361bb1a0.

Reason for revert: See https://crbug.com/v8/6981

BUG=v8:6981

Original change's description:
> [test] Refactor assertPromiseResult
>
> This patch introduces assertPromiseFulfills and assertPromiseFulfills as
> a replacement for assertPromiseResult because it’s more JavaScript-y.
>
> BUG=v8:6921
> R=ahaas@chromium.org
>
> Also-By: ahaas@chromium.org
> Change-Id: I2f865dba3992ddf3b58987bf0b376d143edb5c31
> Reviewed-on: https://chromium-review.googlesource.com/718746
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48578}

Change-Id: Ie760d2422451f16acc616aae001fe9fd18bf5cd4
Reviewed-on: https://chromium-review.googlesource.com/738249Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48936}

Port 266e803e

Original Commit Message:
  This CL adds a first implementation of Liftoff, the new wasm baseline
  compiler, for x64 and ia32. It currently supports the most important
  i32 instructions and control instructions. Whenever it encounters an
  instruction it does not support yet, it aborts.
  In a subsequent CL, Liftoff will be called from the
  WasmCompilationUnit, falling back to Turbofan compilation if the
  baseline compiler bails out.

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

Change-Id: I35ad2b0230c37f523e24aa90b637a67e5ce59083
Reviewed-on: https://chromium-review.googlesource.com/735784Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48935}

The Float32(uint32_t) constructor should not be public, use
Float32::FromBits explicitly if needed.

R=ahaas@chromium.org

Change-Id: I414e621deebde8cdb474f17e08fcc489dbc083cd
Reviewed-on: https://chromium-review.googlesource.com/738173Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48934}

This makes sure flags on newly allocated {Code} objects are initialized
from within the allocator itself instead of after the object has been
created. It essentially makes these flags immutable.

R=jarin@chromium.org
BUG=v8:6792

Change-Id: I6bef183a25508faf1fec28d347956e766e65aecf
Reviewed-on: https://chromium-review.googlesource.com/737633
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48933}

This extends the WASM_EXEC_TEST to also execute the test in Liftoff
(our new baseline compiler).
Use WASM_COMPILED_EXEC_TEST to execute in both compilers, but not in
the interpreter.

R=titzer@chromium.org

Bug: v8:6600
Change-Id: I0b76a5cff9af1b8c4aaec3cceb154ad29ca1b58e
Reviewed-on: https://chromium-review.googlesource.com/733560
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48932}

Current chrome stable has a high number of crashes due to bugs in
this feature. These bugs are already fixed but the fixes are hard
to merge back. Therefore we decided to disable the feature in stable.
This CL is intended to be merged to stable and then reverted in tot.

Bug: chromium:762020
Change-Id: Ibd5a08e3b303a204fb84a408271a1c0f97cc5b7b
Reviewed-on: https://chromium-review.googlesource.com/738176Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48931}

Have JSProxy and JSGlobalProxy use the properties or hash technology
like we use for all other JSReceivers. Also unify and simplify the
code dealing with these hashes.

Bug: v8:6344, v8:6911
Change-Id: Ic995639c74211ba6f33acd73428b8c6d95bf7919
Reviewed-on: https://chromium-review.googlesource.com/737833Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48930}

We have an internal limit of 50000 local variables per wasm function.
This limit is checked when decoding the function body. For asm.js, we
skip function body validation, since by construction the code we
generate is correct. This makes us fail unexpectedly when trying to
(lazily) compile an asm.js function with more than 50000 locals.
Hence, check this limit in the asm parser and bail out if it is
exceeded.

R=mstarzinger@chromium.org

Bug: chromium:775710
Change-Id: I89d2069e133fb0f84947d477ae1ac5eda85571aa
Reviewed-on: https://chromium-review.googlesource.com/732660Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48929}

This is a reland of eeaffa9f
Original change's description:
> [objects] Introduce {CodeDataContainer} object type.
> 
> This introduces the {CodeDataContainer} as a container for all mutable
> fields associated with a {Code} object. For now only the kind-specific
> flags are moved, but more fields can/will be moved gradually. The goal
> is to make all fields in the {Code} header be immutable eventually.
> 
> R=jarin@chromium.org
> BUG=v8:6792
> 
> Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
> Reviewed-on: https://chromium-review.googlesource.com/732987
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48902}

Bug: v8:6792
Change-Id: I31a127df4bb8ee5fedb4d73755df4deae6e1d352
Reviewed-on: https://chromium-review.googlesource.com/738109Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48928}

Following up on adding n-ary nodes, this extends the parser to support
n-ary comma operations, including support for n-ary arrow function
parameters.

Bug: v8:6964
Bug: chromium:777302
Change-Id: Iba9c93b9eaa5a0870815b4fa29e84aa9d0c511e2
Reviewed-on: https://chromium-review.googlesource.com/735156
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48927}

... containing Tuple2 value instead of two properties. This CL reduces the
number of property queries in FunctionToString to one and it is memory-neutral.

Change-Id: Ia6fa267f3e5b6670013f1da3e03cd70bf24dd65a
Reviewed-on: https://chromium-review.googlesource.com/730744Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48926}

R=machenbach@chromium.org

Bug: chromium:777345
Change-Id: I54e8121ada8590d082bcb172668a82e00b5cf248
Reviewed-on: https://chromium-review.googlesource.com/737632
Commit-Queue: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48925}

A WasmCompilationUnit can now either compile the code in liftoff or with
Turbofan. If liftoff compilation fails (because of unsupported
instructions), we fall back to TF.
This new pipeline is only enabled if the --liftoff flag is enabled.

R=titzer@chromium.org

Bug: v8:6600
Change-Id: I63669cfd8b7f0c89b08dcbd4d125d5ed44c7265b
Reviewed-on: https://chromium-review.googlesource.com/733091
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48924}

Bug: v8:6917
Change-Id: Ibc3c738ef807d37d8b76f440d9765c4d0405c021
Reviewed-on: https://chromium-review.googlesource.com/735421
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48923}

R=clemensh@chromium.org

Bug: 
Change-Id: I0c92aa07e10dcd1e9d9fd34dcaf23885076721b0
Reviewed-on: https://chromium-review.googlesource.com/735724
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48922}

There is no need to test each operation on each single memory location.

R=titzer@chromium.org, binji@chromium.org

Bug: v8:6994
Change-Id: Ib401fa1dd4db2e1b9c7ee0b48bb0c1cc9e3f9139
Reviewed-on: https://chromium-review.googlesource.com/735149
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48921}

Expressions of the form

    a_0 + a_1 + a_2 + a_3 + ... + a_n

seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:

           ...
          /
         +
        / \
       +  a_2
      / \
    a_0 a_1

Traversing this tree during compilation can cause a stack overflow when n is
large.

Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form

         n-ary +
       /  |      \
      /   |  ...  \
    a_0  a_1      a_n

The bytecode compiler can now iterate through the child expressions
rather than recursing.

This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.

Bug: v8:6964
Bug: chromium:724961
Bug: chromium:731861
Bug: chromium:752081
Bug: chromium:771653
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}

Use an upper limit search followed by a binary search in the expression
depth test. As our maximum expression depths increase, a simple linear
search wastes cycles.

Bug: v8:6964
Change-Id: I0669e4090f6cc1628d1dec475b9bd8ff52be3f7d
Reviewed-on: https://chromium-review.googlesource.com/735346
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48919}

This reverts commit 37b4b2f1.

Reason for revert: Likely breaking canary.

Original change's description:
> [turbofan] Prune control flow based on failed map checks and comparisons.
> 
> This introduces unreachable state into load elimination. We mark state
> as unreachable if we know statically that a map check would fail.
> When processing effect phis, we disconnect unreachable state's
> control from the effect phi's merge, and point it to RuntimeAbort.
> The control input to the merge is then updated with Dead. Dead
> code elimination prunes the merge, phis and effect phis.
> 
> Bug: v8:6396
> Change-Id: I01874b576e548747a915c7b645b96ebaa6f6700d
> Reviewed-on: https://chromium-review.googlesource.com/730754
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48810}

TBR=jarin@chromium.org,bmeurer@chromium.org

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

Bug: v8:6396, chromium:777843
Change-Id: I6fac6f86e138f33756e688ec30424cb940690dae
Reviewed-on: https://chromium-review.googlesource.com/737829Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48918}

Bug: v8:6644
Change-Id: I47482fa15fa89b1d9cd6c943e89dcc543596de5d
Reviewed-on: https://chromium-review.googlesource.com/738093Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#48917}

This is a reland of a24c7c9a
Original change's description:
> Reuse arch/mode discovery in deopt fuzzer
> 
> Bug: v8:6917
> Change-Id: I1b7169c8702c8649812b17579d38d64de676ed60
> Reviewed-on: https://chromium-review.googlesource.com/723420
> Commit-Queue: Michał Majewski <majeski@google.com>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48838}

Bug: v8:6917
Change-Id: I03b2c288257d44c2df9d0fa6cf4750d1c5719d59
Reviewed-on: https://chromium-review.googlesource.com/735719
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48916}

Bug: 
Change-Id: Ib05bf9abb43872c69102f839876a869c55f8ca48
Reviewed-on: https://chromium-review.googlesource.com/737798Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48915}

Bug: v8:6996,v8:6443
Change-Id: If968750687a8a7c0d1d4c1991c64236ebed55a5b
Reviewed-on: https://chromium-review.googlesource.com/737490Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48914}

This reverts commit e26cd874.

Reason for revert: The issue has been fixed. See related bug for description and CLs.

Original change's description:
> [heap] Add TSAN suppression for lock-order inversion in Scavenger
> 
> The Scavenger currently requires taking the lock for OLD->NEW processing
> and can also take another lock for sweeping a different page.
> 
> Since order of pages during scavenge and sweep is unstable this may
> result in lock order inversion reports on TSAN when long-running
> programms are only executed on a single thread.
> 
> The report is a false positve, hence flag it as suppression until we
> redesign this particular piece.
> 
> No-try: true
> Bug: v8:6923
> Change-Id: I82355be1c8d83ea61cc21152aeb10b58b1dc4b86
> Reviewed-on: https://chromium-review.googlesource.com/716261
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48504}

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

Bug: v8:6923
Change-Id: I7711466c6e2175dcab8d64d6a642e458e1cde3f5
Reviewed-on: https://chromium-review.googlesource.com/738110Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48913}

We were already handling the case that a called import throws, but if
it returned an error which is not convertible to a number, we failed
with a CHECK error.
This CL fixes this.

R=titzer@chromium.org

Bug: chromium:771970
Change-Id: I6c9983459109d49c43304610b696d49de986a250
Reviewed-on: https://chromium-review.googlesource.com/735354
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48912}

E.g. use TrueConstant() instead of BooleanConstant(true) and
NullConstant() instead of HeapConstant(factory...null_value()).

R=jkummerow@chromium.org

Bug: 
Change-Id: I0588d71940d8baf289eb8f8e6c8d20aa717d57f6
Reviewed-on: https://chromium-review.googlesource.com/735681
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48911}

The IsWhite check in the write barrier uses word size memory operations.
It should use 32-bit cell size operation instead.

Bug: v8:6955
Change-Id: I5bbcd99dcd7e3d435f96022a745a6c80c83eb3b3
Reviewed-on: https://chromium-review.googlesource.com/735153Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48910}

R=titzer@chromium.org

Change-Id: I028ec3b2e511079b14454fe0c138715c52e492b9
Reviewed-on: https://chromium-review.googlesource.com/737790Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48909}

All use cases of the RecursiveMutex have been removed.

Bug: v8:6923
Change-Id: I25aeee2447db185dbaacf96ab06a660834a408b7
Reviewed-on: https://chromium-review.googlesource.com/735345Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48908}

Pending the outcome of the discussion on the GitHub issue:
https://github.com/WebAssembly/design/issues/1138

R=clemensh@chromium.org,ahaas@chromium.org

Bug: 
Change-Id: I54a218a93c24cb221b9f0195e2b1abbe6208d8e2
Reviewed-on: https://chromium-review.googlesource.com/735343Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48907}

Now that https://crrev.com/c/728026 has landed, we can construct the
constexpr RegLists using symbolic register names instead of hard-coding
the register codes.

R=titzer@chromium.org

Bug: v8:6600
Change-Id: I21e46aeb5e8598a56f641341bcd7cf718fe4fbf9
Reviewed-on: https://chromium-review.googlesource.com/735548Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48906}

This optimization was disabled because 32-bit builds didn't properly
find certain integer keys in maps anymore. The reason was that the
runtime wasn't using ComputeIntegerHash for the full Signed32 range,
but only for the SignedSmall range.

This change improves the ARES-6 Basic test by around 6-7% on the steady
state.

Bug: chromium:77459, v8:6410, v8:6354, v8:6278, v8:6344
Change-Id: Ifae64e6b23ca8acee4c792be299f64caf951242f
Reviewed-on: https://chromium-review.googlesource.com/737871Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48905}

This reverts commit eeaffa9f.

Reason for revert: Breaks msan compile (uninitialized value in snapshot):
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/17824

Original change's description:
> [objects] Introduce {CodeDataContainer} object type.
> 
> This introduces the {CodeDataContainer} as a container for all mutable
> fields associated with a {Code} object. For now only the kind-specific
> flags are moved, but more fields can/will be moved gradually. The goal
> is to make all fields in the {Code} header be immutable eventually.
> 
> R=​jarin@chromium.org
> BUG=v8:6792
> 
> Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
> Reviewed-on: https://chromium-review.googlesource.com/732987
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48902}

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

Change-Id: I74fe833b074752d640cff4aa4680f250e1bd8780
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6792
Reviewed-on: https://chromium-review.googlesource.com/738029Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48904}