- 23 Jun, 2021 9 commits
-
-
Milad Fa authored
Port e699762e Original Commit Message: Instrument floating-point operations to set a flag if the result is NaN. Does not handle f32x4 and f64x2 results yet. R=thibaudm@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com BUG= LOG=N Change-Id: If81861b65d2a0a98389eebb480127069fd1b5509 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983458Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#75342}
-
Clemens Backes authored
This is a reland of ac654646. Two constants defined in {AssemblerBase} were not defined anywhere, which is fixed now. Original change's description: > [wasm] Remove WasmInstructionBuffer > > {WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer} > which remembered the last {AssemblerBuffer} on {Grow()}. Since the > {Assembler} itself already keeps track of the latest {AssemblerBuffer}, > this functionality is mostly redundant. All we need instead is a method > to retrieve the {AssemblerBuffer} from the {Assembler}. > > This CL thus removes {WasmInstructionBuffer} and instead adds > {AssemblerBase::ReleaseBuffer}. > > R=jkummerow@chromium.org, mslekova@chromium.org > CC=dlehmann@google.com > > Bug: v8:11714 > Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75336} Bug: v8:11714 Change-Id: I8797de1a7a78a93aaef936e46bfd1e73ec2cc9d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982015Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75338}
-
Maya Lekova authored
This reverts commit ac654646. Reason for revert: Breaks ASAN no-inline - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20ASAN%20no%20inline%20-%20release%20builder/22909/overview Original change's description: > [wasm] Remove WasmInstructionBuffer > > {WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer} > which remembered the last {AssemblerBuffer} on {Grow()}. Since the > {Assembler} itself already keeps track of the latest {AssemblerBuffer}, > this functionality is mostly redundant. All we need instead is a method > to retrieve the {AssemblerBuffer} from the {Assembler}. > > This CL thus removes {WasmInstructionBuffer} and instead adds > {AssemblerBase::ReleaseBuffer}. > > R=jkummerow@chromium.org, mslekova@chromium.org > CC=dlehmann@google.com > > Bug: v8:11714 > Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75336} Bug: v8:11714 Change-Id: Iff32952f712ab2f0f9a16d91906d0135c084f4df No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982014 Auto-Submit: 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/master@{#75337}
-
Clemens Backes authored
{WasmInstructionBuffer} was basically a wrapper around {AssemblerBuffer} which remembered the last {AssemblerBuffer} on {Grow()}. Since the {Assembler} itself already keeps track of the latest {AssemblerBuffer}, this functionality is mostly redundant. All we need instead is a method to retrieve the {AssemblerBuffer} from the {Assembler}. This CL thus removes {WasmInstructionBuffer} and instead adds {AssemblerBase::ReleaseBuffer}. R=jkummerow@chromium.org, mslekova@chromium.org CC=dlehmann@google.com Bug: v8:11714 Change-Id: Id07945b67992802a6177bf09e5f5c5be08f657b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982013 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Thibaud Michaud authored
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 authored
If we were unlucky and start wrapper compilation exactly after the isolate started shutting down, we would not have an isolate info any more in the isolate and would access a nullptr. This CL fixes that by just returning an invalid operations barrier token in that case. R=ahaas@chromium.org Bug: v8:11878 Change-Id: I6dcb28a21debb12ba812f705cd5c6387c76eda09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982339Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75334}
-
Milad Fa authored
Detect if Simd is enabled and if so push/pop the entire 128 bit value, if not then only push/pop the double values. Change-Id: I45d54dcf799a685066559cc3521ef44cd884b788 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979352Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#75332}
-
Igor Sheludko authored
... which didn't properly handle non-Smi integer indices with JSTypedArray receivers. The addition of new JSReceiver::OrdinaryDefineOwnProperty() overload with LookupIterator::Key caused circular dependency between lookup.h and js-objects.h, so the LookupIterator::Key was moved out of the LookupIterator class in order to make it forward-declarable. Bug: chromium:1209405 Change-Id: I265f0c00f65ab6476c8f1d0ca1264f555d43465f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972727 Auto-Submit: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
John Xu authored
These are the changes Cobalt currently has in V8's cpu related code. - Add missing Starboard CPU code - Replace some V8_OS_WIN with V8_TARGET_OS_WIN, they are found when cross-compiling for Linux platforms on Windows Bug: v8:10927 Change-Id: Id63ae8614cbe6fe0eb53df89060c8ca2c9969ef4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2963803 Commit-Queue: John Xu <johnx@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75318}
-
- 22 Jun, 2021 8 commits
-
-
Junliang Yan authored
Change-Id: I237f5ad18b82e2e2bf807241ce587a38a27e0b10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979592 Commit-Queue: Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Auto-Submit: Junliang Yan <junyan@redhat.com> Reviewed-by:
Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#75313}
-
Dan Elphick authored
Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into base/strings.h. Bug: v8:11879 Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75308}
-
Andreas Haas authored
In the first CL to introduce a histogram for deserialization time a high-resolution counter was required to get microsecond precision. However, with the histogram we want to detect if we need to optimize deserialization or not. For this information high precision does not matter, it is more important that we get information from all devices. R=clemensb@chromium.org Bug: v8:11862 Change-Id: Id72e25ab7e5ac8217393ab6fd11416187822a158 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2978256Reviewed-by:
-
Junliang Yan authored
Change-Id: If8017e175fe4568ba10889dbb3b88cce897ec57e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972736 Auto-Submit: Junliang Yan <junyan@redhat.com> Reviewed-by:
-
Dan Elphick authored
StringBuilder and its base class SimpleStringBuilder aren't very safe and are a potential source of memory leaks or double-frees. This removes the StringBuilder class and converts all of its usages to use the standard library. (As a drive-by, this converts std::ostream* to std::ostream& which is more idiomatic C++). Bug: v8:11917 Change-Id: I0eaf9d60cf49836e65bb28f0e114b33ef8103a61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2978252 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
We can get rid of this by deferring adding a new global to the module's globals, and using the current size of globals to determine allowed global indices. Bug: v8:11895 Change-Id: Ide80eab2de4abdbab96a7298acf3665599c394ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972908 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
- Add an expected type argument in DecodeWasmInitExprForTesting. This eliminates the need to check for kWasmVoid in consume_init_expr. - Invoke StartDecoding() to initialize module in DecodeWasmInitExprForTesting. - Pass the current module to DecodeInitExprForTesting. - Adjust tests. Bug: v8:11895 Change-Id: I13b71b68a2011bf08742701cb9dd986afd6e55f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972907 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Clemens Backes authored
This is a reland of 0f90a2aa. The issue was inverted destructor order between WasmCodeManager and WasmEngine. WasmEngine has to be destructed first, because it contains a barrier to ensure that background compile threads finished before global state is being destructed. Original change's description: > [wasm] Provide a global WasmCodeManager > > The WasmCodeManager was part of the WasmEngine so far, but there is only > exactly one WasmEngine. Hence we can pull it out, and also remove the > pointer in the WasmCodeAllocator. > > The argument passed from the single constructor call is now inlined in > the constructor itself. > > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just > "CommitPageSize()". > > R=jkummerow@chromium.org > > Bug: v8:11879 > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75270} Bug: v8:11879 Change-Id: I0eaa2395f5c1e30f3f7303c5f3df70c227b74d3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2975859 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
- 21 Jun, 2021 6 commits
-
-
Maya Lekova authored
This reverts commit 0f90a2aa. Reason for revert: Breaks MSAN, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/38941/overview Original change's description: > [wasm] Provide a global WasmCodeManager > > The WasmCodeManager was part of the WasmEngine so far, but there is only > exactly one WasmEngine. Hence we can pull it out, and also remove the > pointer in the WasmCodeAllocator. > > The argument passed from the single constructor call is now inlined in > the constructor itself. > > Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just > "CommitPageSize()". > > R=jkummerow@chromium.org > > Bug: v8:11879 > Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75270} Bug: v8:11879 Change-Id: I110eec313762d73073f530aec7cf0be82c4db344 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972921 Auto-Submit: 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/master@{#75274}
-
Daniel Lehmann authored
Merges `NativeModuleModificationScope` (with an implementation using Intel PKU, if available, and mprotect otherwise) and `CodeSpaceWriteScope` (for Apple Silicon, where switching to RWX with mprotect is disallowed anyway, so MAP_JIT and thread-local switching must be used). Because `CodeSpaceWriteScope` sounded better (and is shorter), we kept its name (which unfortunately makes the diff a bit harder to read). R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: Ib2a7d18e72797a725ed34b904c70769166d811dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972911Reviewed-by:
-
Clemens Backes authored
The WasmCodeManager was part of the WasmEngine so far, but there is only exactly one WasmEngine. Hence we can pull it out, and also remove the pointer in the WasmCodeAllocator. The argument passed from the single constructor call is now inlined in the constructor itself. Drive-by: Replace "GetPlatformPageAllocator()->CommitPageSize()" by just "CommitPageSize()". R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I6c0e74cea308f5806d1aa479945d90b6ef8d1613 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972909 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Daniel Lehmann authored
In an effort to merge `CODE_SPACE_WRITE_SCOPE` and `NativeModuleModificationScope`, this CL moves the interface and implementation of the latter into code-space-access.{h,cc}, where the former already lives. No other changes to the code itself. R=clemensb@chromium.org CC=jkummerow@chromium.org Bug: v8:11714 Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng Change-Id: I1aabce26f2033430523a7a3a0a4864e7267bee21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972803Reviewed-by: -
Clemens Backes authored
There is exactly one WasmEngine per process, hence we do not need to store or pass a pointer to it. We just use {GetWasmEngine} (which just reads a global variable) whenever we need it. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I7e0e86e326f4cafe5a894af0ff6d35803c0340a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972725 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Clemens Backes authored
The WasmEngine is shared across the whole process, so there is no need to store it in every Isolate. Instead, we can just get it from everywhere on any thread using {wasm::GetWasmEngine()}, which is a simple read of a global. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I13afb8ca3d116aa14bfaec5a4bbd6d71faa9aa17 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969825Reviewed-by:Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
- 18 Jun, 2021 8 commits
-
-
Manos Koukoutos authored
It will be used by consume_init_expr(). Bug: v8:11895 Change-Id: I577b5126a3c2cd0a6075ff9f085b4c93a8554846 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972906 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Junliang Yan authored
Change-Id: I568516149f49b7724680d9dfae6e078eb07a8b44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2971552Reviewed-by:
-
Manos Koukoutos authored
When we later introduce an additional template argument to WasmDecoder, we will have to add it here too, as well as in all places which use MemoryAccessImmediate. It is simpler to have a helper function in WasmDecoder to fetch the 64-bit memory status. Bug: v8:11895 Change-Id: I08edbf4e825cd148b30b2a5c0d04a26dfbaed186 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972905 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
Split interface functions into constant, non-constant, and meta functions. This will be useful once initializer expression decoding is implemented as an interface for WasmFullDecoder. Additionally, add ArrayInit() interface function (currently unused). Bug: v8:11895 Change-Id: If076fe47871868c2d754f9c72c865f0a7f9f97d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964609 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
-
Igor Sheludko authored
In order to avoid unnecessary conversions to CodeT and back this CL: - makes compiler::CompileCWasmEntry() return CodeT, - makes Execution::CallWasm() accept CodeT. Bug: v8:11880 Change-Id: Ic4b7b5f476c6efcfca4bc116ecd45cdee9f0c6c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2971743Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75247}
-
Clemens Backes authored
The {WasmCodeManager::CanRegisterUnwindInfoForNonABICompliantCodeRange} method does not access any information on the {WasmCodeManager} object, hence make it static. R=jkummerow@chromium.org Bug: v8:11879 Change-Id: I9a06ec556825bc7709970b65f22156952fa7f191 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972726 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
Daniel Lehmann authored
Currently, we have two different classes for switching the WebAssembly generated code space to writable (e.g., before patching jump tables, or when adding or removing code): `CodeSpaceWriteScope` (with the macro `CODE_SPACE_WRITE_SCOPE`) and `NativeModuleModificationScope`. The former was introduced for Apple Silicon ARM64 hardware ("Apple M1"), which uses `MAP_JIT` + `pthread_jit_write_protect_np()` to change memory permissions. The latter uses either Intel PKU (aka. memory protection keys) to switch permissions (fast and thread-local, like on M1), and alternatively `mprotect()`, on systems that do not have PKU support. Since both classes serve the same purpose just with different implementations on different platforms, we want to merge them in follow-up CLs. As a first step, here we align all uses of `CODE_SPACE_WRITE_SCOPE` with existing `NativeModuleModificationScope`s. The two had diverged due to optimization work, where we moved `NativeModuleModificationScope`s around (pulling them out of loops and across function boundaries) to lower the amount of mprotect switches. This should have none, or at best a very small positive performance impact on Apple M1, since we now also switch less often (even though switching should be very cheap). In terms of security, this in theory makes the code space writable for longer time spans, but this is probably not a large effect because (1) we often moved the scope outside of loops, where it was open for every iteration anyway, or (2) in some cases a CODE_SPACE_WRITE_SCOPE was open somewhere on the call stack already. R=jkummerow@chromium.org CC=clemensb@chromium.org Bug: v8:11714 Change-Id: Id8744429e1183e118ab5e078750d294a99c9dce0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968946Reviewed-by:
-
- 17 Jun, 2021 4 commits
-
-
Igor Sheludko authored
Namely, - WasmFunctionData::wrapper_code - WasmJSFunctionData::wasm_to_js_wrapper_code - exported JS-to-Wasm wrappers Bug: v8:11880 Change-Id: I85f60daea22b8b1270f813f903ebdea1249b4de1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969826Reviewed-by:
-
Andreas Haas authored
At the moment deserialization happens synchronously on the main thread. This is fine at the moment because deserialization is fast. However, future refactorings may affect deserialization time, and may force us to deserialize in the background. This CL adds a timer to monitor deserialization time, so that we get a signal if deserialization time regresses. R=clemensb@chromium.org Bug: v8:11862 Change-Id: I18b52c19106b92158cd986492926a24d0d57e6ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966389Reviewed-by:
-
Thibaud Michaud authored
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:
-
Igor Sheludko authored
Bug: v8:11804 Change-Id: Ief0ade232c4f120b62a6d83f75ed0095abbe797a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966388Reviewed-by:
-
- 16 Jun, 2021 5 commits
-
-
Clemens Backes authored
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:
-
Manos Koukoutos authored
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:
-
Andreas Haas authored
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:
-
Jakob Kummerow authored
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 authored
Bug: chromium:1219630 Change-Id: Idf187bfb16157074b0affda1db3b8ac0b0870e7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964094Reviewed-by:
-
