No-Try: true
Bug: v8:11437
Change-Id: I589e9695a00bea632fa4cfa7575d902872b41e2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719559
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73038}

Port: 96a0677a

Bug: v8:11477
Change-Id: I438a5b833a9838ffa53d30785cf627f75997d7fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719402
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#73037}

Calling CheckForException through the BUILD macro for almost every
invocation of WasmGraphBuilder from graph-builder-interface created
multiple issues:
- It generated an invalid graph with GetExceptionValues, resulting in
  us having to hack CallBuiltin().
- It will generate multiple problems with wasm-gc operations.
- It needlessly slowed down compilation.

Changes:
- Remove BUILD macro, call CheckForException directly only for function
  calls and throws.
- Split CheckForException into a fast inline path and a slow non-inline
  one.
- Move BUILD's DCHECK into CHECK_INTERFACE.
- Add an early exit to Decode().
- Since we do not need the hack anymore, implement CallBuiltin properly.

Change-Id: I38e3c73e0af80894584ce37e2f3bfc90111ac54f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717304
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73036}

Bug: v8:11086
Change-Id: I214ebd0cc7c3b0379fcd6bc78e131fccf7bfe631
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707776Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73035}

This reverts commit ae153904.

Reason for revert: link error in https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20full%20debug/16047/overview

Original change's description:
> [dict-proto] C++ implementation of SwissNameDictionary, pt. 6
>
> This CL is part of a series that adds the C++ implementation of
> SwissNameDictionary, a deterministic property backing store based on
> Swiss Tables.
>
> This CL adds the Add, DeleteEntry, Rehash, and Shrink operations, as
> well as some helpers required by those.
>
> Bug: v8:11388
> Change-Id: I81a181e99e679095c2acc877a293e81b6a581db4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715192
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Frank Emrich <emrich@google.com>
> Cr-Commit-Position: refs/heads/master@{#73020}

Bug: v8:11388
Change-Id: I7c83ddfab6055b992f1580e03aae0da31d83ba63
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718662
Auto-Submit: Francis McCabe <fgm@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73034}

Change-Id: I60683dd37939d330169e3879982a6ac9ca7694a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718230Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73033}

Accidentally omitted this in a previous change
https://crrev.com/c/2686013.

Extract code sequence into macro-assembler for sharing between Liftoff
and TurboFan.

Bug: v8:11348
Change-Id: Ia4e9d1e0dc7a7f3a1a21ff1e1745923a847328cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707773Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73032}

Change-Id: I0723febc3e0d18e68bb629ccd2548108aa662bf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718472Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73031}

arm64 is straightforward, for arm we extract the code sequence into a
macro-assembler function.

Bug: v8:11416
Change-Id: I6dddcee700c497e29f1ee8094cd81adfb1df2f4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707769Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73030}

This reverts commit ea818f07.

Reason for revert: Test failure in Linux64 UBSan https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/15251/overview

Original change's description:
> cppgc: Fix testing APIs that enable garbage collection
>
> The APIs require that the CppHeap is moved into a permanently detached
> state that moves the heap out of a no-gc scope.
>
> Bug: chromium:1056170
> Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73025}

Bug: chromium:1056170
Change-Id: Id00cb18274cbe7d255e7e95bd9e8e4dbc4b0c6e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718658
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73029}

Bug: v8:11086
Change-Id: I67f7aaeb1151b14678d6257a195efd19c86c5fbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707775Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73028}

We also define the getters and setters for the newly
defined registers and their lanes.

Change-Id: I1da9caed5f2f2d9ce79f43d9f70dc994f2200bff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718468Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73027}

Change-Id: Idc8d4e8d99b1a1e82af4c06940c3ca19f103d09f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718470Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73026}

The APIs require that the CppHeap is moved into a permanently detached
state that moves the heap out of a no-gc scope.

Bug: chromium:1056170
Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73025}

- Add a CFunctionBuilder interface to allow adding modifier flags
  to argument types. This will be used to support IDL attributes
  like [EnforceRange], [Clamp], and [AllowShared]. This CL adds
  only the interface, but the actual modifier flags do not exist
  yet as they would not be implemented.
- Remove the internals of the old CFunction type inference and
  implement it on top of CFunctionBuilder.

Bug: chromium:1052746
Change-Id: I09a7cba07105097517a8426a8eeb891393883ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686686Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73024}

Two threads might get the same PersistentNode because the
BasicCrossThreadPersistent ctor wasn't taking a lock. Then if one thread
frees the node and the other initalizes it or updates its owner, we get
some random object in our free list of PersistentNodes.

I debug a crash in Assign(Unsafe) and Clear where the PersistentNode
seemed to be allocated on stack. Empirically, adding this guard resolved
it. I can't confirm in the code that the scenario above is what was
happening.

Drive-by: adding a few DCHECKs.

Bug: chromium:1056170
Change-Id: I37d8ed5bb942a124c98d7524b7f04fe8ccb2aefd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718144
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73023}

... to match what the builtin expects.

Bug: v8:11499, v8:11429
Change-Id: I6e784f6c5109f8d92446e98b8abb7274d5a166a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718151
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73022}

Change-Id: I9b40a06bdfd3b38aa25d05f2c3b8605f480b1236
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718465Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73021}

This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.

This CL adds the Add, DeleteEntry, Rehash, and Shrink operations, as
well as some helpers required by those.

Bug: v8:11388
Change-Id: I81a181e99e679095c2acc877a293e81b6a581db4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715192Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#73020}

This was staged through a back-merge in v8.9. Also stage it for the
upcoming v9.0 release.

R=clemensb@chromium.org

Bug: v8:8091
Change-Id: Ib9e8c33ca258c8b9e407fbcca5db9f0227b558b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718150Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73019}

Currently, some ScopeInfo fields are defined as indexed fields with a
length of either one or zero, because the field might be present or it
might not. Based on comments in https://crrev.com/c/v8/v8/+/2601880 ,
this strategy is not sustainable and we need a better way to represent
optional fields so that we don't have to pass zero when accessing their
only element. This change is a proposal to fix that problem.

Syntax:

I'm proposing using a question mark because TypeScript does, and Torque
syntax looks somewhat like TypeScript. I don't feel strongly about this
though, and I'm open to other suggestions.
  field_name?[condition_expression]: FieldType;

Internal Torque compiler representation:

Internally, I've updated the Torque compiler to still treat these fields
as indexed, but with an extra flag saying they're optional. When getting
a LocationReference for a field access expression on an optional field,
Torque produces a Slice like it would for any other indexed field and
subsequently calls AtIndex(0) to get a Reference.

AtIndex can crash the process if the index is out of bounds (which is
good), so some other parts of the Torque compiler need minor adjustments
so that it doesn't take references to optional fields unless it actually
needs them.

Initialization:

This proposal doesn't include any changes to initialization logic, so an
optional field can still be initialized using '...' and an iterator.
Perhaps we could introduce an Optional<T> struct for prettier
initialization in a future change.

Bug: v8:7793
Change-Id: I37649495f4c259e685261f53e4cf2859da66a31f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706306
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73018}

Port 96a0677a

The precise type is only used for validation. For code generation,
knowing the kind is more than enough. Hence, only store and pass the
ValueKind in Liftoff, and not the full ValueType.

Change-Id: Ia3a07df393b2f93d8d8c51bd41b3bd3a3bd6c6fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715987Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73017}

This reverts commit 1db61fb3.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/34083/overview

Original change's description:
> [wasm][eh] Stage exception handling
>
> This was staged through a back-merge in v8.9. Also stage it for the
> upcoming v9.0 release.
>
> R=​ahaas@chromium.org
>
> Bug: v8:8091
> Change-Id: Ie9e6d25bbc5d428e5c9128345209f95f2078b733
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715524
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73013}

Bug: v8:8091
Change-Id: I18b9706e8aab4883a3d3c120a6cd06e7232aecf7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718148
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73016}

This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 .

I think it makes more sense to list ScopeInfos under "(system)" in the
dev tools, like most other V8 internal types.

Change-Id: If85f869e805d7c374fc7584a79155bb4f400e4b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707249Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73015}

Some helpers that depend on a MachineGraph or WasmGraphAssembler are
moved into WasmGraphAssembler. Also, GetAsmJsOOBValue is inlined.

Change-Id: I8760218cdba1e0f1564cdb044def4a68b348eac3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717303Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73014}

This was staged through a back-merge in v8.9. Also stage it for the
upcoming v9.0 release.

R=ahaas@chromium.org

Bug: v8:8091
Change-Id: Ie9e6d25bbc5d428e5c9128345209f95f2078b733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715524
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73013}

Perform relaxed reads/writes on the builtin index.

Bug: v8:11478, v8:7790
Change-Id: I488fd30e6635f39bb46440e9d5230ab311825e7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716290Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73012}

Port 31aab838

Original Commit Message:

    Extract code sequence into macro-assembler for sharing between Liftoff
    and TurboFan. Relax the register aliasing requirements (remove the
    DCHECKS), this will not affect codegen for TurboFan since the
    instruction selector already sets the correct restrictions, but makes it
    more flexible for use in Liftoff.

R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I729095aae0412fce70ec97a1d7c5f27d32b1a932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718143Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73011}

Bug: chromium:1056170
Change-Id: Ib2b2788c7d59f873583e26a0716bacbf16766c93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716291Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73010}

Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/

Currently, wasm loop unrolling is disabled by default. We intend to
further investigate its compilation time cost and running time benefits
before enabling it.

Additional changes:
- Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight
  loop analysis.
- Move EliminateLoopExit into LoopPeeling and expose it.
- Introduce loop_info_ field into WasmGraphBuildingInterface, fill it
  up in Loop().
- Break after encountering the first loop in BuildNestedLoopExits.
- Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated
  in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction
  to be filled up by WasmGraphBuildingInterface, and then passed to
  GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase.
- Introduce WasmLoopUnrollingPhase and insert it into the wasm
  compilation pipeline.
- Fix an issue where exception values were not wrapped in
  WasmGraphBuilderInterface.
- Update --wasm-loop-unrolling flag description.

Bug: v8:11298
Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73009}

This adds a re-compilation of top level functions in
getPossibleBreakpoints if no candidates could be found.
This step is necessary as the GC may remove SharedFunctionInfo about
top-level functions.

Bug: chromium:1137141
Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73008}

Change-Id: I60b9cb6e0f7552fbdc35b62b6b379c8ac5f203e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716323Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#73007}

The available constants are now:

 JSObject {
  kMaxElementCount = kMaxUInt32,
  kMaxElementIndex = kMaxElementCount - 1,
 }

 JSArray {
  kMaxArrayLength = JSObject::kMaxElementCount,
  kMaxArrayIndex = JSObject::kMaxElementIndex,
 }

I also updated the codebase to use the new constants.

Change-Id: I3142f9ff9627c9acb1d4493729b490150fdcdf50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712755Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73006}

It had essentially become a synonym for BytecodeArrayAccessor.
This removes the BytecodeArrayIterator class and renames
BytecodeArrayAccessor to BytecodeArrayIterator.

Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73005}

Bug: v8:10855
Change-Id: I0f28603421ba36176d177bfcc25f18a26a097c29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716062Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Gus Caplan <snek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73004}

We were using CmpInstanceType instead of CmpObjectType in some places,
which meant that we were reading the value at the instance type field
offset within objects directly, rather than first loading their map and
reading the instance type there.

Bug: chromium:1180434
Change-Id: I4771b4f8f9a32bdc35944c6e6cd30c54e4ac8b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716292
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73003}

Bug: v8:11321
Change-Id: Ica350e9a613d6dddb17569ce5b2df072ceb2c050
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717156
Auto-Submit: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73002}

These functions are defined in WasmGraphBuilder, so we do not need to
invoke them in mcgraph() or gasm_.

Change-Id: Ibd97add56d22bff7eb99addd78bf599057b21041
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717302Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73001}

Assert that the lock is help whenever AssignUnsafe is called.
LazyMutex::AssertHeld resolves to a DCHECK so this should not
regress production performance (other than the call itself
that might not be inlined).

Bug: chromium:1056170
Change-Id: Ic2005d180e6960c24dff7743aa3e0d5e57a63d80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716286Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73000}

Bug: v8:7790
Change-Id: Iae4374e352aea0169d4fe1eba5d825c16efe3940
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715198
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72999}