The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97

br_on_exn (which was done in another CL) and also rethrow should trap on
nullptr. This CL implements this by an explicit check in the builtin
called for rethrow.

R=jkummerow@chromium.org
CC=aheejin@chromium.org

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

The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97

br_on_exn (and also rethrow, which will be added in another CL) should
trap on nullptr. This CL implements this by an explicit check on each
br_on_exn (within {GetExceptionTag}). This check will be redundant if
several br_on_exn follow each other. Since also the runtime call for
{GetExceptionTag} is redundant, and also the fact that we do a runtime
call is suboptimal, I consider the whole implementation prototypical for
now anyway.

R=jkummerow@chromium.org
CC=aheejin@chromium.org

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

Don't use deprecated HTML Imports, directly fetch the template files from
html instead.

Bug: v8:10155
Change-Id: Ic85a8b2cf227231fc6abf5adca6f1f144bf728f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113371Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66825}

The spec was changed such that traps are not catchable in wasm:
https://github.com/WebAssembly/exception-handling/pull/93

This CL implements this in V8 by adding a private symbol as a property
to all uncatchable exceptions. It also adds a number of tests.

R=jkummerow@chromium.org
CC=aheejin@chromium.org

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

During off-thread space merge, we free the linear allocation area in the
off-thread space. Since the off-thread space isn't marked, we have to
make sure that we don't try to compensate for black allocated live bytes.

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

Change-Id: I5a424f6349d2f71de1dccdcedb0d98d50c68fc98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113379Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66822}

Remove unused breakpoints as we hit them. OSR in this case does not work
properly yet, because we are missing the source position for the removed
breakpoint in the new code.

R=clemensb@chromium.org

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

On Linux, Perfetto translates the builtin "ts" timestamp in trace event
from CLOCK_MONOTONIC to CLOCK_BOOTTIME, before passing them to devtools.
Devtools therefore implicitly operates on timestamps that are in
CLOCK_BOOTTIME.

However, additional timestamps sent in trace event payload arguments
will not be converted to CLOCK_BOOTTIME by Perfetto, raising the
possibility of devtools using timestamps from multiple clock domains
incorrectly.

Since trace events sent by CpuProfile also include the builtin "ts"
trace timestamp (sampled from CLOCK_MONOTONIC nearly at the same time by
the tracing framework), sending "data.startTime" and "data.endTime" is
essentially redundant. devtools-frontend:2113957 stops the use of the
value of these timestamps in the payload of Profile and ProfileChunk
events. Devtools continue to use the presence of these arguments to
indentify start and end profile events.

ProfileChunk events also include "timeDeltas" which are relative
timestamps. They are also in CLOCK_MONOTONIC and are not translated by
Perfetto. devtools-frontend:2113957 computes absolute CLOCK_BOOTTIME
timestamps from timeDeltas by adding them to "ts" in the "Profile" event
(previously, "data.startTime" was used). This is only valid if the
system is not suspended/resumed during profiling. Providing support for
suspend/resume in the middle of profiling will likely involve having
Perfetto convert "timeDeltas" directly to CLOCK_BOOTTIME.

This CL introduces no code changes and only adds comments to explain
the above.

BUG=chromium:1055871

Change-Id: I649dfcce8ea1a100c0ecfe03f843c7cb1fdd6f33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114001
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66820}

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: I2c49093585fbd6e9ba1fe777492188d64625dc92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111222
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66819}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/b53200e..bf3f9ee

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/39af23e..bf306f5

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

Change-Id: I2f928720575546690e7df15830ce53d27bba211d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114656Reviewed-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@{#66818}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/192f1d2..b53200e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/cc4989c..39af23e

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5416b3a..befc299

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

Change-Id: I611df71694bae2f0450ca2de2cbcc8a4916b45b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2114102Reviewed-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@{#66817}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9e8017c..192f1d2

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/df670f0..cc4989c

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/464e9ff..5416b3a

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/689fb3d..105a846

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

Change-Id: Id8ed92bec0bdf65f55b78e92a65e281b73d0f677
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113103Reviewed-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@{#66816}

New Rev: b7cda08cd6e522df2159413ba5f29d2a953cc1c4

Upstream Review:
"Drop redundant std::move in inspector_protocol."
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2112636

Change-Id: If7832adf00f1c574960e5ca3c179e7b03255fc86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113132
Auto-Submit: Johannes Henkel <johannes@chromium.org>
Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66815}

Port a447a44f

Original Commit Message:

    Since now the IterationBody StackChecks are implicit within JumpLoops,
    we are able to eagerly deopt in them. If we do that, whenever we advance
    to the next bytecode we don't have to advance to the next literal
    bytecode, but instead "advance" in the sense of doing the JumpLoop.

    Adding tests that test this advancing for wide and extra wide JumpLoops.

    Also, marking JumpLoop as needing source positions since now it has
    the ability of causing an interrupt.

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

Change-Id: I5bec2212d040801d67426a8639d20fe96035d813
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111832Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66814}

Upstream PR:
"Introduce a crdtp/dispatch.{h,cc} library."
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1974680
"For the shallow parse of a DevTools message, allow "params": null."
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2109466

New Revision: c69cdc36200992d21a17bf4e5c2f3a95b8860ddf

Change-Id: Icc447ff9ce408b24f5245c643dd2f1843da9255f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076215
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66813}

Introduces a new macro BUILD_V (v is for vector) that pushes bytes into
a vector (instead of directly in an array initializer, see BUILD). This
has the positive effect of being able to handle opcodes of multiple
bytes (e.g. SIMD opcodes bigger that 0xfd80). Because of this "API"
change, our helper macros in test-run-wasm-simd.cc and wasm-run-utils.h
need to change too. So, we introduce new macros (suffixed by _V), that
will call the appropriate lambdas defined in BUILD_V, that knows how to
push bytes into the vector, and also can handle multi-byte opcodes.

This design has a bit of duplication and ugliness, but was chosen to
reduce the impact of existing tests. No restructuring of test code is
required, we only need to add suffix _V.

Note that we do not have multi-byte opcodes yet (in wasm-opcodes.h),
this change will be breaking, and requires all the tests to be updated
to use _V macros first.

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

Now that it is implicit in function entry and loop iteration, there is
no need for an explicit bytecode.

Also updated tests that used explicit bytecodes.

Bug: v8:10149, v8:9960
Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66811}

This CL provides a generic way to prepare a builtin call: The
{PrepareBuiltinCall} takes the builtin signature for 64-bit systems,
the CallDescriptor, and a Vector of VarStates for the parameters, and
moves all parameters to their correct place, which is either in a
register or on the stack.

To test the new code this CL adjusts the implementation of AtomicWait
to use PrepareBuiltinCall. Thereby AtomicWait is now also supported
on 32-bit platforms, including ia32.

R=clemensb@chromium.org

Bug: v8:10108, v8:10281
Change-Id: Ia8589166310ea2e8442531b4ed20db62d7b4aff0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108554
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66810}

Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.

Adding tests that test this advancing for wide and extra wide JumpLoops.

Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.

Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}

Bug: v8:10201
Change-Id: I72cbe15912395b9b06ffdccce935abae6e7a050e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093508Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66808}

Squash a couple of remaining places where compilation finalization was
allocating new-space objects.

Bug: chromium:1011762
Change-Id: Ie0462eed422016f860146724a06dd2f1963bd88e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110019
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66807}

When spill a range without register uses inside a loop, it is beneficial to spill the range ealier at the loop header to reduce memory moves from the back edges.

The changes to FindOptimalSpillingPos are motivated as follows:
 - Change “next_use->pos() < pos” to “next_use->pos() <= pos”.
  The former version causes a crash of mksnapshot in debug build,
  because it is possible that a UsePosition at a split point gets split
  to the previous range according to “DetachAt”. For example, we
  have a live range with:
    UseIntervals: [1, 20[
    UsePosition: 10
  When split the live range at position 10, we will get:
    Range 0:0: UseInterval: [1, 10[
               UsePosition: 10
    Range 0:1: UseInterval: [10, 20[

 - Change “NextUsePositionRegisterIsBenefitial” to
   “NextRegisterPosition”, because there’s always a
   “Define” use position at the loop header for those phis
   that do not require a register. Using the original check
   will hence not apply the optimization.


Change-Id: I3b0bb3687ba572f1d3fc1892cefae7e866d99baa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094964Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Yolanda Chen <yolanda.chen@intel.com>
Cr-Commit-Position: refs/heads/master@{#66806}

Ensure that the off-thread pages' marking bits (including the page
headers) are correct, and synchronised correctly on merge.

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

The FpRegister size was miswritten as kSimd128Size like x64, while it
should be kDoubleSize on mips.

Change-Id: Iac4c5687e398a87ec0508fb99042a487c41ddf8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110891
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66804}

I'm unable to produce an issue with this test locally, so let's
try to enable it again.

Big: v8:6587
Change-Id: Ida834ac4ccf8c25d8f5c1e09fc57479db46a1873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108722
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66803}

This is patching 560f2d8b for a
failing android-binary-size bot, see
https://chromium-review.googlesource.com/c/chromium/src/+/2110413

TBR=rmcilroy@chromium.org

Bug: chromium:747064
Change-Id: I37c5484afa427420d7a4614300556f7a5e99b21d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111211Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66802}

Bug: chromium:1062916
Change-Id: Ic29ca849fb17c1409cc11018fdbc9d3363ebd55c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110027
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66801}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9b1394c..9e8017c

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8413a03..df670f0

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/6e39ba4..689fb3d

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

Change-Id: If6421082ec9f3e737d9892778cffec143136cbcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111138Reviewed-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@{#66800}

The src register needs to be different from the temporary Simd128
register since in the codegen we modify tmp before using tmp and src.

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

This is a reland of e80ca24c

Original change's description:
> [regexp] Rewrite error handling
>
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
>
> 1. Depending on whether the stack overflows during parsing or
>    analysis, the stack overflow message can vary ("Stack overflow" or
>    "Maximum call stack size exceeded"). I kept that behaviour in this
>    patch, under the assumption that stack overflow messages are
>    (sadly) the sorts of things that real world code ends up depending
>    on.
>
> 2. Depending on the point in code where the error was identified,
>    invalid unicode escapes could be reported as "Invalid Unicode
>    escape", "Invalid unicode escape", or "Invalid Unicode escape
>    sequence". I fervently hope that nobody depends on the specific
>    wording of a syntax error, so I standardized on the first one. (It
>    was both the most common, and the most consistent with other
>    "Invalid X escape" messages.)
>
> 3. In addition to changing the representation, this patch also adds an
>    error_pos field to RegExpParser and RegExpCompileData, which stores
>    the position at which an error occurred. This is used by
>    SpiderMonkey to provide more helpful messages about where a syntax
>    error occurred in large regular expressions.
>
> 4. This model is closer to V8's existing MessageTemplate
>    infrastructure. I considered trying to integrate it more closely
>    with MessageTemplate, but since one of our stated goals for this
>    project was to make it easier to use irregexp outside of V8, I
>    decided to hold off.
>
> R=jgruber@chromium.org
>
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}

R=jgruber@chromium.org

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

This CL introduces a CSA builtin for the TableCopy instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.

The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.

R=clemensb@chromium.org

Bug: v8:10281
Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66797}

Chrome uses the new version now.

Bug: v8:8116
Change-Id: I59af8d2c6a897a852acd6de3a7938a4b8d3943e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110015Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66796}

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

Bug: chromium:1062763
Change-Id: I70d44f2db06b5ec1d84ab6678582dfc559d47e7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108729
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: David Manouchehri <david@davidmanouchehri.com>
Cr-Commit-Position: refs/heads/master@{#66794}

Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on interpreter and
arm64.

These operations are behind wasm_simd_post_mvp flag, as we are only
prototyping to evaluate performance. The codegen is based on guidance at
https://github.com/WebAssembly/simd/pull/201.

Bug: v8:10308
Change-Id: I835aa8a23e677a00ee7897c1c31a028850e238a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2099451Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66793}

This CL introduces a CSA builtin for the TableInit instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.

The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.

The CL also introduces a small CSA function which takes an uint32 value
and a max value as parameters and returns a Smi of the minimum of these
two.

R=clemensb@chromium.org, ishell@chromium.org

Bug: v8:10281
Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66792}

Add some more code comments for code snippets that are not obvious,
especially if debug code is enabled.
The comments help when looking at Liftoff code for debugging code
generation issues.

R=thibaudm@chromium.org

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

1) Replace a condition by a DCHECK.
2) Remove dead argument.

R=thibaudm@chromium.org

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

Update the "hook on function call" flag also in the wasm case, and
slightly change the {IsStepping} logic to stop in any frame if the last
step action was anything other than StepNext.
In future CLs, this has to be extended further for StepOut and for
StepOver at a return location.
When that is done, we can also reenable more stepping in the test.

R=thibaudm@chromium.org

Bug: v8:10321
Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66789}

Currently, when GeneratePrintDefinitionsForClass generates its Print
functions it uses a string literal as the newline character for all the
last lines. For example:

void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint(
    std::ostream& os) {
  this->PrintHeader(os, "TorqueGeneratedStruct");
  os << "\n";
}

The last line could use a single character instead of a string,
for example:

void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint(
    std::ostream& os) {
  this->PrintHeader(os, "TorqueGeneratedStruct");
  os << '\n';
}

The commit suggests changing this into a char.

Change-Id: Id7a2f5fb17108fcbb543109d18b6b474ac1c5d2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108546Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66788}