This is a partial revert of https://crrev.com/c/2033171 to bring back
WasmModuleObject::Compile, that compiles Wasm bytes into a Wasm module.
Also adding a simple test to make sure the compile works.
There are some users, e.g. Cloudflare, Halide, see bug for more details.
Bug: v8:10461
Change-Id: I199abea108311025decad793d2232a08bba05d38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3292088
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78003}
This is a reland of 45227ffdb4
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}
This reverts commit 45227ffdb4.
Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77566}
Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.
Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
HeapConstant Factory::zero_string(). However, NumberToString does
not always produce this string. To avoid regressions, the CL keeps
the HeapConstant type and changes the runtime and builtin code to
always produce the canonical "0" string.
A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.
Drive-by fix: a few minor Torque issues that came up.
Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}
Was a clang bug that has since been fixed, https://crbug.com/1163847.
Fixed: v8:11134
Change-Id: Idf2c4bcd8f07024e64e38289793e3af74f43e98c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212808
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77324}
Certain collators and subject strings may take this new fast
path without calling into the (slow) ICU comparison functions.
This CL can be roughly split into three topics:
1. The fast path check, precomputed and implemented as a whitelist
on the current locale string.
2. The actual fast path, which checks subject string eligibility
and performs L1 and L3 collation weight comparisons all in one pass.
3. Resuming from an aborted fast-path into the generic path.
A longer overview is available at
https://docs.google.com/document/d/1oyDwjYn2JyHsx2YnJJKhjX0WMNQXb8ao86-DRzqiYNg/edit?usp=sharing
JetStream2/cdjs scores improve by roughly 40%.
Bug: v8:12196
Change-Id: I5e1bbd731a36c361af9667f9104d6fa15c42e117
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3149463
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77284}
Liftoff is temporarily disabled on PPC.
After https://crrev.com/c/3202593 the newly skipped tests
are failing with this error:
```
Check failed: tester.native_module()->GetCode(0)->is_liftoff()
```
Change-Id: I681a27930909fd6ac4e5087c2d03608b891a6066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208070
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77265}
With dynamic tiering, typically not all functions of a WebAssembly
module get compiled with TurboFan, and therefore the code caching would
never get triggered. With this CL code caching is triggered whenever
{FLAG_wasm_caching_threshold} bytes of TurboFan code are generated.
This new caching event is only triggered when --wasm-dynamic-tiering is
enabled.
R=clemensb@chromium.org
Bug: v8:12281
Change-Id: I939325aea7e4310aa76c936636799661c05d4079
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3202593
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77251}
Due to MIPS64 ISA feature, 32-bit values should be sign-extended
in 64-bit registers, no matter it's signed or unsigned.
Besides, LoongArch64 also has this feature, and a similar change
has been made before loong64 port's land in V8. This CL also make
a small fix for loong64.
Change-Id: Ib284662931082365f727925af61781e3653debc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193595
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#77154}
The intent of the RISC-V ISA is that 32-bit C values are stored sign extended in registers, even for unsigned types.
So we skip cctest case RunLoadStoreZeroExtend64/RunUnalignedLoadStoreZeroExtend64 due to sign extend uint32
Change-Id: Icfe727916b1c04aad5681902ec4782cc98906964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3184560
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77112}
.. by reusing the regexp stack from potentially multiple nested
irregexp activations.
To do this, we now maintain a stack pointer in RegExpStack. This stack
pointer is synchronized at all boundaries between generated irregexp
code and the outside world, i.e. when entering or returning from
irregexp code, and when calling into C functions such as GrowStack.
Fixed: v8:11382
Change-Id: I5ed27630c1a64ebf3afb9ddf80fb60ea067c0c40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162604
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77013}
Liftoff needs to be fully implemented for running this test.
Change-Id: Ia229d478fa22d4ce9a715d13b3d2b09a2634ad1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163016
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76870}
This test is added in commit bc3b9332ac
Bug: v8:7748
Change-Id: I8bada39c6fc9ed22f7a25786697aed880738bc9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163286
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76868}
This is a reland of deb66c84c0
Added missing cctest.status entries to disable the tests on
non-simd hardware.
Original change's description:
> [wasm] Add tests for NaN detection in Liftoff
>
> Check that the flag is also set if only one of the lanes is NaN for SIMD
> operations.
>
> R=clemensb@chromium.org
>
> Bug: v8:11856
> Change-Id: I3860ed1beac4faee1ade7180b67ca06762ca9b95
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158322
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76801}
Bug: v8:11856
Change-Id: If45451703d80fe217eac8c610dac022dc778436f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3158329
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76812}
The test should be enabled once reentrancy is supported.
Bug: v8:11382
Change-Id: Ifb90d8a6fd8bf9f05e9ca2405d4e04e013ce7ee3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138201
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76667}
Instrument floating-point operations to set a flag if the result is NaN.
Port: e699762e06
Bug: v8:11856
Change-Id: Iae8121dd17ae8acf402ac74e41122cad77387db7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099945
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#76605}
This is a reland of faf2208a0b
Changes since revert:
- Fix arm64 codegen for full pointer mode
Original change's description:
> [compiler] Support acq/rel accesses and atomic accesses on tagged
>
> This CL adds an AtomicMemoryOrder parameter to the various atomic load
> and store operators. Currently only acquire release (kAcqRel) and
> sequentially consistent (kSeqCst) orders are supported.
>
> Additionally, atomic loads and stores are extended to work with tagged
> values.
>
> This CL is a pre-requisite for supporting atomic accesses in Torque,
> which is in turn a pre-requisite for prototyping shared strings.
>
> Bug: v8:11995
> Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76393}
Bug: v8:11995
Change-Id: I23577486334fec6b08fb3a2f5be1f6e5e16db11b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107220
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76399}
This reverts commit faf2208a0b.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression/10870/overview
Original change's description:
> [compiler] Support acq/rel accesses and atomic accesses on tagged
>
> This CL adds an AtomicMemoryOrder parameter to the various atomic load
> and store operators. Currently only acquire release (kAcqRel) and
> sequentially consistent (kSeqCst) orders are supported.
>
> Additionally, atomic loads and stores are extended to work with tagged
> values.
>
> This CL is a pre-requisite for supporting atomic accesses in Torque,
> which is in turn a pre-requisite for prototyping shared strings.
>
> Bug: v8:11995
> Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76393}
Bug: v8:11995
Change-Id: Id9936672f9e96c509b1cdf866de1ac5303996945
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3107229
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#76394}
This CL adds an AtomicMemoryOrder parameter to the various atomic load
and store operators. Currently only acquire release (kAcqRel) and
sequentially consistent (kSeqCst) orders are supported.
Additionally, atomic loads and stores are extended to work with tagged
values.
This CL is a pre-requisite for supporting atomic accesses in Torque,
which is in turn a pre-requisite for prototyping shared strings.
Bug: v8:11995
Change-Id: Ic77d2640e2dc7e5581b1211a054c93210c219355
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3101765
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76393}
This is a reland of a3b2c4ec81
The fix is in PS3, for UBSan. We use WriteUnalignedValue for
potentially unaligned memory writes.
Original change's description:
> [wasm][diagnostics] Support WasmCode in gdb JIT integration
>
> - Add new enum WASM_CODE to JitCodeEvent::CodeType
> - Use AddressRegion instead of AddressRange (remove the latter)
> - Change CodeDescription constructor to take an AddressRegion,
> both JIT_CODE and WASM_CODE use this
> - Add a simple mjsunit test that sets --gdbjit to check that
> we don't crash.
> - Add a api test for adding WASM_CODE
>
> Bug: v8:11908
> Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76271}
Bug: v8:11908
Change-Id: I5ded6d01cff40803b2f70525163f760edcf97165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76327}
Bug: v8:12008
Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76308}
This reverts commit a3b2c4ec81.
Reason for revert: UBSan https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8839060153390139249/+/u/Check/gdbjit
Original change's description:
> [wasm][diagnostics] Support WasmCode in gdb JIT integration
>
> - Add new enum WASM_CODE to JitCodeEvent::CodeType
> - Use AddressRegion instead of AddressRange (remove the latter)
> - Change CodeDescription constructor to take an AddressRegion,
> both JIT_CODE and WASM_CODE use this
> - Add a simple mjsunit test that sets --gdbjit to check that
> we don't crash.
> - Add a api test for adding WASM_CODE
>
> Bug: v8:11908
> Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76271}
Bug: v8:11908
Change-Id: Ic1a74a9239e8ef6107efd36f61c089ae6bfc5b6c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093365
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#76274}
- Add new enum WASM_CODE to JitCodeEvent::CodeType
- Use AddressRegion instead of AddressRange (remove the latter)
- Change CodeDescription constructor to take an AddressRegion,
both JIT_CODE and WASM_CODE use this
- Add a simple mjsunit test that sets --gdbjit to check that
we don't crash.
- Add a api test for adding WASM_CODE
Bug: v8:11908
Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76271}
These are no longer enabled, so remove the code mitigation logic from
the codebase.
BUG=chromium:1003890
Change-Id: I536bb1732e8463281c21da446bbba8f47ede8ebe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045704
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76256}
Forgot to do this in crrev.com/c/3067226.
Bug: v8:7790,v8:12030
Change-Id: Ic6fbf3feb07e8d08f0fd83d76d54535387c7a27c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074464
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76117}
Based on a CL by mvstanton@.
Bug: v8:7790,v8:12030,v8:12031,v8:12041
Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76055}
pthread_rwlock_t can deadlock on Mac if signals are sent to the process
in the wrong moment. Since we use processes e.g. for sampling profiling
(in both d8 and in Chrome), we hence cannot safely use pthread_rwlock_t
on Mac. Instead, fall back to a non-shared pthread_mutex_t.
Interestingly, this shows no measurable performance impact in Wasm
compilation on my MBP.
R=mlippautz@chromium.org
Bug: v8:11399
Change-Id: Ie8bfd5288bba8c4f3315ee4502b39b59d39c9bbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060480
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76015}
- Implement f32/f64 fcopysign
- Implement f32/f64 type conversion
- enable some test cases that now pass.
Change-Id: Ia36299484adac885349df25d7c233dd7e43dded4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992914
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75690}
Instrument floating-point operations to set a flag if the result is NaN.
Does not handle f32x4 and f64x2 results yet.
R=clemensb@chromium.org
Bug: v8:11856
Change-Id: I1c3603e2c0c92e71bea8418e85852c01904379af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979600
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75335}
* Skip 8 tests that timeout due to the low-performance of current MMTk non-moving GC.
- This will be enabled after TPH performance issues are addressed.
* Skip 2 new tests that creates a second isolate -- TPH does not support it at the moment.
* Skip 1 test that expects concurrent sweeping behavior of cppgc.
Bug: v8:11641
Change-Id: If86cdcc303b01536d278368886bb30d91da5c5c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909692
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75036}
Add a new testing tier based on Liftoff. In this tier, the Liftoff
compiler takes an address to a counter, and decrements that counter at
every instruction. When the counter reaches 0, execution aborts.
R=clemensb@chromium.org
Bug: v8:11856
Change-Id: I20970e323ff19f7cb6ab6855377c678ca391421e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944440
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75022}
These tests require Simd enabled which causes failures
on machines without the support.
They are already skipped on Mips: https://crrev.com/c/2841887
Change-Id: I4b9a9bb3cb208a0e9aa12dc135393bc515ad766e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2927210
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74891}
CallWithArrayLike was optimized in TF only for 'arguments' in inlined
functions. Here we add logic to optimize also in non inlined functions,
enabling the rewriting of Function.prototype.apply(f, [1, 2, 3])
as f(1, 2, 3).
Bug: v8:9974
Change-Id: Icc9ccfc2276f75d06755176b55e7a02ddfdb04ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2805623
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74723}
This adds a new status file indicator "HEAVY" to mark tests with high
resource demands. There will be other tests running in parallel,
but only a limited number of other heavy tests. The limit is
controlled with a new parameter --max-heavy-tests and defaults to 1.
The change also marks a variety of tests as heavy that recently had
flaky timeouts. Heavy also implies slow, hence heavy tests are
executed at the beginning with a higher timeout like other slow tests.
The implementation is encapsulated in the test-processor chain. A
new processor buffers heavy tests in a queue and adds buffered tests
only if other heavy tests have ended their computation.
Bug: v8:5861
Change-Id: I89648ad0030271a3a5af588ecc9c43285b728d6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905767
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74712}
The combination of pthread_rwlock_t and signals causes spurious
deadlocks on Mac (see linked issue).
This adds a cctest which tests this combination. This test is skipped on
Mac, where it would deadlock. This test can be used to document and
further investigate the issue, and test potential fixes.
R=jkummerow@chromium.org
Bug: v8:11399
Change-Id: I5d1fcdd84db253ec2d0637575239f212aae2ecb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2856553
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74662}
This is the second reland of 4683d6fe52
Initial CL: crrev.com/c/2874663
First reland: crrev.com/c/2886861
The first reland fixes Ref construction failures in:
- MapRef::instance_descriptors
- NativeContext reads (see also crrev.com/c/2891575)
The second reland (this CL):
- Adds required infrastructure (e.g. kAssumeMemoryFence) but
without enabling the IsPendingAllocation check. Enabling the check
will be done separately to avoid further revert chains.
Original change's description:
> [compiler] Consider IsPendingAllocation in Ref construction
>
> The logic in JSHeapBroker::TryGetOrCreateData assumes that parts
> of the object are safe to read. In particular, the instance type
> must be readable for the chain of `Is##Name()` type checks.
>
> This is guaranteed if
>
> - a global memory fence happened after object initialization and
> prior to the read by the compiler; or
> - the object was published through a release store and read through
> an acquire read.
>
> The former is protected by the new call to ObjectMayBeUninitialized
> (which internally calls IsPendingAllocation) in TryGetOrCreateData.
>
> The latter must be marked explicitly by calling the new
> MakeRefAssumeMemoryFence variant.
>
> Note that support in this CL is expected to be incomplete and will
> have to be extended in the future as more cases show up in which
> MakeRef calls must be converted to MakeRefAssumeMemoryFence or to
> TryMakeRef.
>
> Bug: v8:7790,v8:11711
> Change-Id: Ic2f7d9fc46e4bfc3f6bbe42816f73fc5ec174337
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874663
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74474}
Bug: v8:7790,v8:11711,chromium:1207680,chromium:1207679
Change-Id: I123b2962df724a13dd2c7334ae949234bc3bf27a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902738
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74638}
