MemoryChunkLayout::MaxRegularCodeObjectSize() can be cached in a
global variable on process initialization. This should help to increase
code object allocation performance, since this method was called on
each code object allocation.

Bug: v8:11891
Change-Id: I870bd37202370aec89ef2db24264e363099bf8a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966387
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75215}

WebAssembly.Exception is the static representation of a wasm exception.
It holds the signature and the tag of the exception, can be imported and
exported from a wasm module, and will eventually allow inspecting a
wasm-thrown exception from JS.

R=clemensb@chromium.org

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

`NumRegs` runs a `population count` and must be used with
a `RegList` and not with a regular integer value.

kCallerSavedDoubles is a regular integer and should be used as is.

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

Bug: v8:11804
Change-Id: Ief0ade232c4f120b62a6d83f75ed0095abbe797a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966388Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75212}

Change-Id: Ic36d34ca928b2dbc7427f60818dbd612b386e7a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967709Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75211}

Change-Id: I541973c5b0570c1a1c23ce8e09cd20d3904df749
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966198Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75210}

Mark the write of the property as relaxed atomic. The compiler thread
is examining the value. It is fine if the value is stale or new, we
simply need to let TSAN know we are aware of the race.

BUG=v8:11896

Change-Id: I42505a6e12c7eb3c1ef8d9376d7a420567646d62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968403Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75209}

The PropertyArray may store the hash of it's parent object. This hash
can be installed at various points. Meanwhile, the background compiler
thread inspects the length field.

BUG=chromium:1220974

Change-Id: I7b13fd4546fb48e649fcbf67dee02d7c668393f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967471
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75208}

This CL adds
- CodeT type - an alias for CodeDataContainer or Code depending on
  whether the v8_enable_external_code_space is enabled or not,
- a set of conversion functions from CodeT to Code or CodeDataContainer
  and back (both in C++ and CodeStubAssembler),
- masm support for calling/tailcalling via CallDataContainer which
  contain the code entry point address,
- masm support for calling/tailcalling via CodeT.

Bug: v8:11880
Change-Id: Ib36f4c6db69ec49aaea29412647e59ada95da19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967463
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75207}

Bug: v8:11234
Change-Id: I5fa2d97e01df25171c2a80aafb265b508176b334
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967470
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75206}

Bug: v8:11234
Change-Id: I6b3d3a72ad272b8b98e58c0de02b6a9b3dcfb5a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967466
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75205}

This finishes the TSAN support for loads as we do not use movb or movw
to load from memory

Bug: v8:7790, v8:11600
Change-Id: I3c319da95c24cfa03f4de2367e007fd4cf7dd355
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953321Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75204}

Bug: chromium:1213393
Change-Id: I100c5caba38cab3a1ef9511125937ef7b34d818f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966381Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75203}

Change-Id: I19b06e8590e7555e64b3ad59b2f0defe504f87ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933502Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75202}

Bug: chromium:1213393, chromium:1218340
Change-Id: Icde33c97d39a3504ca2ab8290ec2f0b0d923060d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953194
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75201}

Adds support to webassembly and enables it by default.
Adds wee8 target.

We can compile without wasm with:
`bazel build :d8 --no//:v8_enable_webassembly`

Bug: v8:11234
Change-Id: I90b11eb71aed808005b66e40e37894616d8b1658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960803
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75200}

Change-Id: I0a614fa6c381770f56037f0401db008a37c71dca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966209
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75199}

Adopt Windows ARM64 related source to Builtin changes:
https://chromium-review.googlesource.com/c/v8/v8/+/2949104

Bug: v8:11892
Change-Id: I267aac720c832ce11ce2708a92e212241b368ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964605Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75198}

Fuzzing found a problem with --turbo-optimize-apply when the
Array.prototype iterator is replaced with a generator function.
We can the issue by installing a protector on the array iterator.

This CL also defines the --turbo-optimize-apply as 'future' to get
more test coverage.

Bug: v8:9974
Change-Id: Id5bc68fde98ea5d1f6a951c4381ca6283b892632
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966058
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75197}

Bug: v8:11898
Change-Id: If0e3c21a2b1b84ae81ac962417cdf91ca78a95c6
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967464
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75196}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bc21621..1a575de

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/be7dcbc..466954e

Rolling v8/buildtools/linux64: git_revision:72d5a6e15d868abc8451fe0a3b6596e86a2ffc40..git_revision:d2dce7523036ed7c55fbb8d2f272ab3720d5cf34

Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/7e85c7a..a38ef11

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/6434229..96bc38d

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/e319aba..74ef838

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/c6949cb..66b4484

TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

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

LGTM1 Mike West mkwst@chromium.org
LGTM2 Chris Harrelson chrishtr@chromium.org
LGTM3 Yoav Weiss yoavweiss@chromium.org

Design Doc:
https://docs.google.com/document/d/1cPGfiihn76yj2iAomKcspPFyLLcnk3WkCiqceBQPQyk
R2T: https://groups.google.com/a/chromium.org/g/blink-dev/c/W7TcX1tSHDI/m/1AthUhEWBAAJ
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/TpAvyXwHM_c/m/QXJKbClfAwAJ
Stage in m92 Canary 92 92.0.4500.0 Dev 92 92.0.4503.3 Beta 92 92.0.4515.40
https://chromiumdash.appspot.com/commit/eb6482784ca71d3b22db449fd941bfa9872d244a


Bug: v8:7051, v8:11868, v8:11869
Change-Id: Id1ae20234b764e6f6def83af651daf70056d0725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2950559Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75194}

To enable deallocation of CodeEntry objects after they're no longer
being referenced by an active profile or alive on the heap, replace the
|used| bit with a proper reference count maintained by a CodeMap.

Bug: v8:11054
Change-Id: I3016cdbcbd1b4e8a26c3b1689e968cb2eef8e6d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965493Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#75193}

Port c7949470

Original Commit Message:

    ... when we do have an isolate. This is a little leaner.

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

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

Empty function bodies can actually reach the compiler. We could prevent
this by making this a decoder error instead, but that would be a
redundant check, so we should just remove the DCHECK instead.

R=ahaas@chromium.org

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

Add tests for Intl Locale Info API to ensure the return items fit the
type definition in UTS35

Bug: v8:11887
Change-Id: Ie92d80518909df9472ffd887800832a656807b5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964597Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75190}

The object may have been poisoned again between marking and compaction
through executing pre-finalizers or custom weakness handling of
related objects.

Bug: chromium:1220666, chromium:1056170
Change-Id: Ibba4b42852a2921640d6f3ded473521febb2114f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966386Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75189}

When pushing/popping registers, we need a way in PPC and S390
to detect if Simd registers need to be pushed or not.

On PPC Simd registers are separate from FP registers, hence we
need to push them both. If Simd is not available then we push
an empty space in place of Simd registers.

On S390 the Simd and FP registers are shared. If Simd is available
then we only push them and not the FPs, else we push FP registers
as well as an empty space the size of FPs as the stack needs to look
like as if Simds were saved too.

We also need to check if we are generating builtins or
call is being made at runtime. We cannot use `SupportsWasmSimd128`
when generating builtin as `CpuFeatures` are turned off, so we need
to emit the `if/else` manually for checking the value of
`SupportsWasmSimd128`.


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

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

In heap-refs.cc, GetOwnFastDataPropertyFromHeap() bottlenecks reading
a fast property. To make it safe to use from the background thread we
need to verify the object didn't shrink, and risk an out of heap
bounds read.

Bug: v8:7790
Change-Id: Idebbe0ffea089bf2a70aa7d611618430169082fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928185Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75186}

This mutex wasn't really used anymore. This should also speed up
code object allocation a bit.

Bug: v8:11888
Change-Id: I8ddc2ecc1aec74e8eb3e2d4b96354c50f3bff350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966382Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75185}

Rather than letting a recursive macro expansion cause a stack overflow
and crash the compiler, this change updates Torque to emit an error as
soon as the recursion is detected. Eventually it would be nice to make
Cast macros a little more magical so they don't require so much human
effort to maintain, but at least this way Torque displays some
information about what went wrong. An example error message (manually
wrapped to 72 character width) follows.

src/builtins/cast.tq:157:10: Torque Error: Recursive macro call to
  callable Cast<(class Context | Undefined | Zero)>(implicit class
  Context)(Object): (class Context | Undefined | Zero)
src/builtins/cast.tq:758:3: Torque Error: Note: in specialization
  Cast<(class Context | Undefined | Zero)> requested here
src/builtins/cast.tq:764:10: Torque Error: Note: in specialization
  Is<(class Context | Undefined | Zero), Object> requested here
src/builtins/torque-internal.tq:64:3: Torque Error: Note: in
  specialization UnsafeCast<(class Context | Undefined | Zero)>
  requested here
src/objects/contexts.tq:75:10: Torque Error: Note: in specialization
  ReferenceCast<(class Context | Undefined | Zero), Object> requested
  here
src/builtins/iterator.tq:142:16: Torque Error: Note: in specialization
  ContextSlot<class Context, class Context, (class Context | Undefined |
  Zero)> requested here

Bug: v8:11727
Change-Id: I7b5b1852dee16a6860f593f27783f6b2d9366146
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965032Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75184}

On a loop back edge both the cached instance and the cached memory
start have to get restored for the next loop iteration. In the original
CL we did not consider the case that by restoring the instance we may
overwrite the currently cached memory start.

Original description:

WebAssembly functions often have subsequent memory accesses, and each of
these memory accesses need the start address of the memory in a register.
With this CL the register with the memory start address is cached, so
only the first memory access has to load the memory start address into a
register, subsequent memory accesses can just reuse the register.

In first measurements with the epic benchmark this reduces the size of
the generated Liftoff code by a bit more than 5%.

R=clemensb@chromium.org

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

No-Try: true
Bug: v8:11893
Change-Id: Iee4164cc25f736f4d9aa0b24319e947215439938
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964607
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75182}

... when we do have an isolate. This is a little leaner.

Change-Id: Ia95d9888b11cab9e43362f4fe78689a79dfa8b2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964604
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75181}

When we pass function arguments on the stack, untagged parameters
"come first", i.e. are put to lower addresses / can be popped off
first. So when a function instructs the stack walker to visit its
parameters (belonging to its caller's frame), it must skip past
any untagged parameters at the top of the caller's frame.

Change-Id: I5a42e4850b0808237ae937c90b0cec930df8571b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964394
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75180}

... behind the v8_enable_external_code_space build flag.

This is a first CL in a row of CLs that will make CodeDataContainer
the only type of objects that could contain references to Code objects
(besides the Code objects embedded into the generated code).
Eventually these changes will allow us to move Code space out of the V8
heap cage.

This CL adds |code| field to ensure that CodeDataContainer keeps the
respective Code object alive and |code_entry_point| field that contains
cached value of the code().InstructionStart().

Bug: v8:11880
Change-Id: Ie7ce75667d8da306797d203691b429671bc4530d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964093
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75179}

Since DiscardCompiled() can allocate, it could also a cause a GC. A full
GC might perform bytecode flushing, which could change the return value
of CanDiscardCompiled(). So a DiscardCompiled() invocation in one loop
iteration could violate the assumption that CanDiscardCompiled() holds
in subsequent iterations. Prevent DCHECK failure by checking whether
CanDiscardCompiled() still holds for each SharedFunctionInfo.

Bug: v8:11772
Change-Id: Ie9c704abeea801bd3f4f1bdf8fa9c51a8a9d447d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960274Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75178}

Bug: chromium:1219630

Change-Id: Idf187bfb16157074b0affda1db3b8ac0b0870e7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964094Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75177}

Now you can also clean build directories: x64.optdebug.clean
Or clean and build: x64.release.clean.d8

No-Try: True
Change-Id: I3df59416d4ce7db5306c0b09c9ee8293c7a345f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964595
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75176}