GlobalSize will be used as a hint to schedule scavenger work in
https://chromium-review.googlesource.com/c/v8/v8/+/2036661
This is implemented as an atomic variable that's updated when adding/removing
segments.
Bug: chromium:1012816
Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66175}
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB
if the physical memory size is greater or equal to 16GB on 64-bit
platforms.
This CL also adds tests for configuring heap limits from the physical
memory size.
Bug: chromium:1045034
Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66174}
We used to optimize functions that are expected to executed only
once by not allocating feedback slots for some of the bytecodes. This
would help in reducing the memory and avoiding initializing feedback
that would be never used. With lazy feedback allocation, we don't
allocate feedback vectors for most of such functions anyway.
The generated bytecode for oneshot optimized functions is different and
if we don't properly track this information we might end up generating
different bytecode for the same function. This could causes problems
when there is a mismatch between the feedback slots used by the new
bytecode and the old bytecode. Since we potentially get most of the
benefits of this optimization with lazy feedback vector allocation
we can simplify the code by disabling this optimization.
Bug: chromium:1045824
Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66172}
Allow caching the result of allocating AstConsStrings, to allow
sharing of inferred names between functions.
This is a partial revert of https://crrev.com/c/2020953, with
the observation that *some* AstConsStrings are always flattened,
while others are only ever used as ConsStrings, so we want to
allow the allocation to be lazy while still caching the result.
As a drive-by, cleanup the old AstConsString linked list fields.
Bug: chromium:1011762
Bug: chromium:1048082
Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66168}
This is a reland of 410ca4c50e
Skip new test for unsupported liftoff architecture.
Previously, if there is some unsupported liftoff functions, it fall
through Turbofan but recompilation didn't catch and count it. This CL
fixes it by using requested_tier on finished units.
Avoid to tier down asm.js.
Introduce reached recompilation tier to monitor recompilation progress.
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=szuend@chromium.org,bmeurer@chromium.org
Bug: v8:9654
Change-Id: I6014ae52d1e04726e64ee9267c5ce559090414d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031744
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66164}
With "Value::parseBinary" now being revamped by https://crrev.com/c/2020518
and making use of "cbor::ParseCBOR", the extra endianness check
is not needed anymore as "ParseCBOR" already switches
the byte order in this line:
crdtp/cbor.cc
void ParseUTF16String(CBORTokenizer* tokenizer, ParserHandler* out) {
....
for (size_t ii = 0; ii < rep.size(); ii += 2)
value.push_back((rep[ii + 1] << 8) | rep[ii]);
...
"String16EndianTest" does not go through the newly added pipeline
and "ParseUTF16String" is never used which makes the test redundant.
Change-Id: I6ad59fef7036c70d475b492407fd394977ca98f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038716
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66160}
A pointer-compressed heap has the same heap limit heuristics as a 32-bit
heap. Specifically, the heap limit is restricted to 1GB due to scarce
virtual addresses space on 32-bit platforms. That limitation does not
apply for pointer-compressed heaps which can use 4GB.
This CL changes the heap limit computation to use system the pointer
size instead of the tagged pointer size. Note that the young generation
limit continues to use the tagged pointer size.
Bug: chromium:1045034
Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66159}
Add off-thread support for literals, including object/array boilerplates.
Notably, this includes adding FixedArray and HeapNumber support to
OffThreadFactory.
As a drive-by, OffThreadHandle is redefined to store an Address rather
than an Object, similar to Handle, so that it still works with forward
definitions of types.
Bug: chromium:1011762
Change-Id: I7c8452f450d8c57fe683a9e44532ce5647c84a11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036084
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66156}
The source position is set to the function call (console.log) not the
spread (..x), in the bytecode generator, as the spread operation is
done as part of the CallWithSpread bytecode.
The CallPrinter stops at the function call and doesn't look at the
arguments as well (in CallPrinter::VisitCall) to see if the error is
from an incorrect spread operation.
With this patch, we pass some state to the CallPrinter in the
CallWithSpread error case and check that in CallPrinter::VisitCall
before returning.
For the given source string:
```
x = undefined;
console.log(1, ...x);
```
Previously, the error was -
```
test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
console.log(1, ...x);
^
TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
at test.js:2:9
```
Now, the error is -
```
_test.js:2: TypeError: x is not iterable (cannot read property undefined)
console.log(1, ...x);
^
TypeError: x is not iterable (cannot read property undefined)
at _test.js:2:9
```
Bug: v8:10038
Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66131}
If new Liftoff code is generated but we already have either Liftoff or
TurboFan code, we still want to install and use the new Liftoff code if
we are in debugging.
This logic can probably be simplified again when the "tier down to
liftoff on Debugger.enable" logic is fully implemented. I left a TODO to
revisit the logic later.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ie3a6bdf1cde4f1af884edc8cf1f1b5a507283a5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036089
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66129}
These instructions were probably leftover from an earlier cleanup. We
can move them into respective macro lists, then delete away the
redundant declarations, definitions, disasm, and tests.
We were missing disasm tests for SSE2_INSTRUCTION_LIST_SD, so add that
in.
Change-Id: I8f27beaf57e7a338097690073910a0863f00b26a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036833
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66123}
The instruction selector assumed for Word32AtomicPairCompareExchange
nodes that if there exists a Projection(1) user, then there also exists
a Projection(0) user. This, however, is not the case, because TurboFan
eliminates unreachable nodes. The missing projection node lead to a
failed DCHECK in the register allocator.
With this CL we allocate the right registers for the existing
projections, and allocate the other needed registers as temp registers.
R=gdeepti@chromium.org
Bug: v8:10140
Change-Id: Id50768c3cb712db5e0eb3b9dcd0a8a479e20953a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030731
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66122}
This relands commit 5cfe053e45.
Original change's description:
> [wasm-simd][liftoff] Add S128 case for stack movements
>
> The two cases we are fixing here are Construct and
> LoadCallerFrameSlot, which are closely related.
>
> Construct is called during PrepareCall, where we build up
> LiftoffStackSlots when we need to move an arg from caller's stack frame
> into callee's stack frame. LoadCallerFrameSlot is the parallel to
> this, called in ProcessParameter during decoding of the callee's
> function body.
>
> In most cases, Construct needs a new case to handle kWasmS128, and calls
> the relevant assembler to push a s128 onto the stack.
>
> ARM64 requires 16-byte alignment of sp, so we need to Claim the right
> number of kXRegSize slots first, which requires
> us traversing the list of slots to figure out how many s128 values there
> are. This is a straightforward way to fix this, if efficiency is a
> problem, we can change LiftOffStackSlots::Add to sum up the slot sizes.
>
> On IA32, pushing s128 values will require 4 calls to push. Instead, we
> use a sub and two movdqu, which will generate less code in most cases.
>
> On x64, there is no 128-bit push, so we call push twice.
>
> Bug: v8:9909
> Change-Id: I3af35b8462ea9c3b9b2d90800c37d11b5e95be59
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2015945
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65956}
Bug: v8:9909
Change-Id: Icdaead289abe13faf75bb9e049929f7fd7c59a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036760
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66119}
The debug side table is indexed by pc offset. Offsets change if
breakpoints are added or removed, hence we cannot reuse the debug side
table when compiling another version of the function (with a different
set of breakpoints). Thus store the debug side table per code object
instead of per function.
R=thibaudm@chromium.org
Bug: v8:10147
Change-Id: Ifd77dd8f43c9b80bc4715ffe5ca8f0adca2aaf42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030922
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66110}
This is mostly used for regression tests which don't need that function.
If we want to wrap it for inclusion in an existing test file, we can
easily add a function around it, and name it properly.
R=ahaas@chromium.org
Bug: v8:10177
Change-Id: I2aedcdfad09fe1fe07af9f0caa2b8bd45da902f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036077
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66102}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
This changes how we setup modules from being entirely bytecode based to a
single fixed array with metadata that's passed into a runtime function
DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
replace the bytecode that calls those functions with explicit calls before we
even start running the code. In the case of modules that will obviate the need
for modules to be generators.
Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66097}
If we need a byte register, but {src} is none, we should definitely use
another register.
R=ahaas@chromium.org
Bug: chromium:1048241
Fixed: chromium:1048241
Change-Id: I3396826986e1823250ad6855b84f4b05faaf3b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036073
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66095}
When the embedder integrates in V8's garbage collector the performance
of the atomic phase is sensitive to how much embedder memory is found
through marking the overall transitive closure.
Before this patch, V8 would help out tracing the embedder's heap when
making progress through tasks but not on allocations. In addition, V8
would complete the garbage collection when it has observed it's own
marking worklists as empty 3 times (*). This can create performance
cliffs when there's a lot of work still to be done on the embedder
side.
This patch adds helping steps on allocation that are proportional to
the bytes that V8 would otherwise process, guaranteeing some progress
as long as there's V8 allocations. This allows us to remove (*).
Potential Tradeoffs:
- More time spent in V8's garbage collection metrics as we slightly
limit the chances for the embedder to mark objects through tasks.
- Prolonged V8.execute time (JS execution)
+ Faster progress
+ Less memory
+ Smaller atomic pause time
Change-Id: I160f063209f7e129b9c884206f833706b69dadc1
Bug: chromium:1044630
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2025371
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66091}
This relands commit 7c32fa05df.
Some test cases need to be updated, since we will bail out to TurboFan
where previously Liftoff was happy to run, when SIMD is not supported.
Original change's description:
> [wasm-simd][liftoff] Check CpuFeatures for SIMD support
>
> If Wasm simd128 is not supported on this particular hardware, we bail
> out to TurboFan.
>
> Bug: v8:9909
> Change-Id: Ie46e154426783ba099b7c0facc906670cda1bdd0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029427
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66055}
Bug: v8:9909
Bug: v8:10169
Change-Id: I850e1fe6bfbd12fb2eec052aa8367624c09f7a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030354
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66090}
After allowing larger strings on 64-bit builds, this test OOMs on
Android devices that don't have enough memory.
Tbr: machenbach@chromium.org
Change-Id: I05c44d7074388a4306e5266ba1aa9da760c83377
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035877
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66089}
The assembly of sqrtpd when using Sqrtpd macro was wrong, since
Sqrtpd(xmm1, xmm1) will incorrect generated vsqrtpd(xmm1, xmm1, xmm1),
which is nonsensical, since vsqrtpd only takes two operands. The
expected instruction should be vsqrtpd(xmm1, xmm0, xmm1) in terms of the
encoding, which is vsqrtpd(xmm1, xmm1).
So, move sqrtpd and cvtps2dq out into their own macro list, because
they have two operands in their AVX form, unlike the rest of the
instructions in SSE2_INSTRUCTION_LIST.
Also updated disasm and tests to use this new list.
Fixed: v8:10170
Change-Id: Ia9343c9a3ae64596bbc876744556e1dcea2a443b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2032195
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66088}
This CL implements functionality to allow an embedder to mark a
debug scope as terminate-on-resume. This results in a termination
exception when that debug scope is left and execution is resumed.
Execution of JavaScript remains possible after a debug scope is
marked as terminate-on-resume (but before execution of the paused
code resumes).
This is used by blink to correctly prevent resuming JavaScript
execution upon reload while being paused at a breakpoint.
This is important for handling reloads while paused at a breakpoint
in blink. The resume command terminates blink's nested message loop
that is used while to keep the frame responsive while the debugger
is paused. But if a reload is triggered while execution is paused
on a breakpoint, but before execution is actually resumed from the
breakpoint (that means before returning into the V8 JavaScript
frames that are paused on the stack below the C++ frames that belong
to the nested message loop), we re-enter V8 to do tear-down actions
of the old frame. In this case Runtime.terminateExecution() cannot be
used before Debugger.resume(), because the tear-down actions that
re-enter V8 would trigger the termination exception and crash the
browser (because the browser expected the tear-down to succeed).
Hence we introduce this flag on V8 that says: It is OK if someone
re-enters V8 (to execute JS), but upon resuming from the breakpoint
(i.e. returning to the paused frames that are on the stack below),
generate a termination exception.
We deliberated adding a corresponding logic on the blink side (instead
of V8) but we think this is the simplest solution.
More details in the design doc:
https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
Bug: chromium:1004038, chromium:1014415
Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
This is a reland of 9781aa076f
Original change's description:
> Reland "[wasm] Cache streaming compilation result"
>
> This is a reland of 015f379aa1
>
> Original change's description:
> > [wasm] Cache streaming compilation result
> >
> > Before compiling the code section, check whether the
> > bytes received so far match a cached module. If they do, delay
> > compilation until we receive the full bytes, since we are likely to find
> > a cache entry for them.
> >
> > R=clemensb@chromium.org
> >
> > Bug: v8:6847
> > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66000}
>
> Bug: v8:6847
> Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66047}
Bug: v8:6847
Change-Id: I272f56eee28010f34cc99df475164581c8b63036
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66081}
Define a macro in code-generator-x64 to help identify cases when the
shift value is an immediate/constant. In those cases we can directly
emit the shifts without any masking, since the instruction selector
would have modulo-ed the shift value. We also don't need any temporaries
in this case.
This is only x64 codegen, optimizations for other archs will come in
future patches (and will probably look very similar to this).
The current test case passes the shifts as an immediate, so we add a new
path that loads the shift value from memory, thereby exercising the
slower path of non-immediate shift value.
Bug: v8:10115
Change-Id: Iaf13d81595714882a8f5418734e031b8bc654af3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2026067
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66074}
This relands commit e8832647b6.
The flaky test failures seems to be related to tiering, Liftoff
generating different call descriptors from TurboFan when Simd128
is unsupported (since TurboFan will lower the graph, but Liftoff
can continue running simd-call.js just fine).
We temporarily disable tiering for this test, until we get a proper fix,
like https://crrev.com/c/2029427/, but that fix requires this change
since more tests will fail without the lowering fixed.
Bug: v8:10169
Bug: v8:10154
Original change's description:
> [wasm-simd] Fix scalar lowering of kParameter
>
> Lowers the call descriptor of a wasm function if it contains simd.
>
> Also fixes a couple of issues with the lowering of kParameter:
> - the old_index == new_index check is incorrect, it would only work if
> the s128 parameter is the first parameter
> - the old_index was also not adjusted to account for Parameter[0] being
> the wasm instance object
> - new_index needs to be adjusted to account for the instance object too
>
> These fixes make it more similar to the lowering of kParameter in
> int64-lowering.c.
>
> Also add a new mjsunit test to exercise this logic.
>
> Bug: v8:10154
> Change-Id: Ia767a464c26a6a78fd931eab9e6897890a0904e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020521
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66032}
Change-Id: I1e27825025aefc5a42aeeb87d0447d6594388fa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029147
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66072}
We will use this state in devtools via the inspector to indicate
whether a thread is currently stuck polling in atomics.wait.
VMState already distinguishes the important states we care about which
are idle vs. running JS. We also want to know the state for
atomics.wait(), which is commonly used in WebWorkers to poll the main
page for work to do.
This CL just adds and maintains the state and adds assertions in
atomics tests. Another CL will emit inspector notifications when the
VMState changes in a way that the inspector cares about.
Re-flow comments as a drive-by cleanup.
Bug: chromium:1025490
Change-Id: I961051bfb846aa20454a56214310370ea8e47d1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2033168
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66071}
The flag is unused.
Bug: chromium:1044630
Change-Id: Ib499cdd559451c9f23c3c98b187755ef6748bffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030743
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66070}
This adds two flags for whitelisting natives on fuzzers:
--allow-natives-for-fuzzing:
Enables a small subset of runtime functions and replaces others with
undefined.
--allow-natives-for-differential-fuzzing
Restricts the allowed runtime functions even further, excluding the
ones that break differential fuzzing.
Bug: chromium:1044942
Change-Id: I890bd4a6ff7c2e483dd74155290a7ace06f85239
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020773
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66068}
Factory::NewFunction now requires names passed into it to be flat.
Make sure to flatten Wasm function names when creating new Wasm JS
functions.
Fixes: chromium:1047368
Change-Id: I7bd2d8bc83ae8fab901ab469872bce0f703fc3ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030738
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66064}
This shipped in v7.9, which is stable since six weeks. We do not test
the previous configuration any more and don't plan to move back, hence
remove the flag and clean up the code.
R=ahaas@chromium.org
Bug: v8:10155
Change-Id: I6b981f4be686473a911f041952cb684749d9fe7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030732
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66063}
As discussed offline, the current implementation implement each
situation separately. I think we can simplify the code a lot by sharing
code between the different paths.
This CL does that by
1) implementing the kI64Store case separately, because it does not have
all the register contraints that the others have, and
2) moving all logic to ensure that the {src} register is usable before
the switch, such that it's shared by all the compare-exchange cases.
As a side produce, this also fixes issue 1045225, because for i64 stores
which actually only use the lower half of {src}, only that half will be
pinned.
R=ahaas@chromium.org
Bug: chromium:1045225, v8:10108
Change-Id: I0be025b9706d563835ae6337d45b88e0233eacad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029414
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66062}
On backends that do not have s128 support in Liftoff, tests will bail
out to TurboFan, so tests will continue running and passing.
Bug: v8:9909
Change-Id: I3b596a73b6cb2e8645a99c65a935026f9e1a8d55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029332
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66056}
This reverts commit 410ca4c50e.
Reason for revert: This was causing Chrome to hang when debugging large wasm binaries.
Clean revert except for modification to test/debugger/debugger.status
Bug: chromium:1047210, v8:9654
Original change's description:
> [wasm] Tierdown wasm module upon "Debugger.enable"
>
> Put a logic in Wasm Engine to tier down all existing modules per isolate
> when debugger is enabled. This CL does not handle new module added after
> debugger is enabled yet.
>
> Bug: v8:9654
> Change-Id: I87060f5c416506543fcaf231bff9999d06ba4c0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013692
> Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66017}
TBR=clemensb@chromium.org,bmeurer@chromium.org,duongn@microsoft.com,szuend@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9654
Change-Id: Id49e8c69f8212e95e698d7e7267056fb2eb7e60a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030737
Auto-Submit: Eric Leese <leese@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66054}
There was a bug in the function body decoder where
type checking of brtable only happened if the brtable
instruction is reachable. However, type checking is
required in all cases where brtable "not unreachable".
The difference between reachable and "not unreachable"
is a state called spec-reachable where a clever
compiler can already infer that the code will be
unreachable (e.g. a memory access is out of bounds
just by the offset and therefore unconditionally
traps), but the spec can not. If an instruction is
only spec-reachable, it still has to be type checked.
R=clemensb@chromium.org
FIX=chromium:1046472
Change-Id: I7e9f1108597871615c0d443a0e94de35a0207b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66049}
This is a reland of 015f379aa1
Original change's description:
> [wasm] Cache streaming compilation result
>
> Before compiling the code section, check whether the
> bytes received so far match a cached module. If they do, delay
> compilation until we receive the full bytes, since we are likely to find
> a cache entry for them.
>
> R=clemensb@chromium.org
>
> Bug: v8:6847
> Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66000}
Bug: v8:6847
Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66047}
This patch adds a new BackingStore::Reallocate function that internally
uses a new ArrayBuffer::Allocator::Reallocate provided by the embedder.
The default implementation of the function simply copies the backing
store. The embedder can override the function and provide a more
efficient implementation e.g. using realloc.
Bug: v8:9908, v8:9380
Change-Id: I2179c80ba199c045b6900c620a813916150e7098
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007274
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66044}
... by using random seed provided via --gtest_random_seed= flag.
Bug: chromium:1043117
Change-Id: I6114e9c71f3196a386a8457a6ec6f9e1fc80f6ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027991
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66043}
Remove AstConsString "internalization", and instead make the conversion
to heap String be on-demand with an Allocate method. We never actually
need the heapified cons string more than once, so there's no need to do
the internalization walk or do the next/string union dance in the
AstConsString class.
This also allows us to specify how we want to allocate the String at the
call site. In particular, it allows us to allocate a flat SeqString rather
rather than a ConsString. This allows us to avoid allocating ConsStrings
which will just be passed to a flatten call, and especially avoid
allocating dead ConsStrings in the off-thread old space.
Bug: chromium:1011762
Bug: chromium:1043168
Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66042}
When the file begins with a hashbang, the scanner is in a failed state
when SkipHashbang() is called. This is usually not an issue but when
the parser encounters an ILLEGAL token, it will reset the SyntaxError
location because of it.
Bug: v8:10110
Change-Id: I1c7344bf5ad20079cff80130c991f3bff4d7e9a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995312
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66038}
