The I64x2Mul overwrote the lhs/rhs if they are the same as dst. So when
deciding if we need temporaries, we should not only check the
cache_state, but whether they alias dst or not.
Bug: chromium:1088273
Change-Id: I82efa9b45e0a3d321a06efde60971ce95b21490f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2225796
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68114}
Allocating a new feedback vector happens in two steps: We create an
empty structure and then initialize the array based on the
FeedbackMetadata.When allocating a new feedback array we could trigger
a GC which might flush the bytecode and associated feedback metadata.
This shouldn't happen in normal cases, because we either allocate
feedback vector after compilation or when we reach the expected budget.
In both cases, the age of the feedback vector should be 0 and hence
bytecode shouldn't be flushed. However, with debugger enabled we may
allocate feedback vectors even when the bytecode array is old
for example: when we enable precise invocation counters. This also
causes issues in tests with --stress-flush-bytecode. In the stress mode
we flush bytecode without considering the age. Holding on to the
feedback metadata prevents crashes in such cases.
Bug: v8:10560
Change-Id: Ie806ff4102cb5fcf257c8683d5ca957853e38c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218066
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68052}
Temporarily disable stress-bytecode-flush on
mjsunit/regress/regress-786784 while we investigate failures related
to bytecode flushing.
Bug: v8:10560
Change-Id: Ieb5cc7ba87da04133e98c6be25c9a499d79543e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218038
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68046}
In BinaryOpAssembler::Generate_BinaryOperationWithFeedback, the
feedback is stored only after the respective builtin/runtime call.
If this call throws an exception, the feedback is lost, leading
to a deopt loop in some cases. This CL fixes that issue by writing
the gathered feedback before passing control to the builtin.
Bug: chromium:1077197, v8:9441
Change-Id: I20e4b14815520224e2c6f8af1af6a89f754ccddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202904
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68038}
This is a reland of 6204768bab
The original issue exposed the problem that NumberEqual performs
implicit conversion of oddballs to numbers, which is incorrect for
abstract equality comparison (i.e. 0 == null must not be true).
This reland fixes this by applying the following steps:
* Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
* In CodeStubAssembler::Equal: Further distinguish between boolean and
non-boolean oddballs and set feedback accoringly.
* In JSTypedLowering: Construct [Speculative]NumberEqual operator with
CompareOperationHint::kNumberOrBoolean, when this feedback is present.
JSOperatorBuilder and operator cache are extended accordingly.
* In SimplifiedLowering: Propagate a UseInfo with new
TypeCheckKind::kNumberOrBoolean.
* This leads to the generation of CheckedTaggedToFloat64 in
RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
* In EffectControlLinearizer: Handle this new mode. Accept and convert
number and boolean and deopt for rest.
Original change's description:
> [turbofan] Improve equality on NumberOrOddball
>
> This CL cleans up CompareOperationFeedback by replacing it with a
> composable set of flags. The interpreter is changed to collect
> more specific feedback for abstract equality, especially if oddballs
> are involved.
>
> TurboFan is changed to construct SpeculativeNumberEqual operator
> instead of the generic JSEqual in many more cases. This change has
> shown a local speedup of a factor of 3-10, because the specific
> operator is way faster than calling into the generic builtin, but
> it also enables additional optimizations, further improving
> runtime performance.
>
> Bug: v8:5660
> Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67645}
TBR: tebbi@chromium.org
Bug: v8:5660
Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68037}
There was a legacy place in map code that wasn't fully ported to use
the strong, new SloppyArgumentsElements type because of code that used
hard-coded constants.
Bug: chromium:1086470
Change-Id: Ieba152e4bd92c89125f831949c2efb4f4219f95c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215059
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67984}
We can't consistently rewire the successor blocks of an unreachable node to
disconnect them from the graph when we are trying to maintain the schedule.
Instead simply leave the code there. As a future optimization we could add a
proper scheduled dead code elimination phase which can deal with this.
As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
in the instruction selector.
BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67953}
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using
s1x2.anytrue in our opcodes. This was a legacy naming, because we were
trying to bitpack the booleans. Now that we aren't doing that, rename
these to be more consistent with the proposal.
This was done with a straightforward sed script, changing both cpp code
and also some comments in mjsunit test files.
Bug: v8:10506
Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67945}
This was introduced by https://crrev.com/c/2207137.
Load offsets can be negative.
Drive-by: Add a helper function to wrap the verbose static casts in
bounds checks.
Bug: chromium:1084872,chromium:1083450
Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67924}
Registers cannot be used as a merge destination if they have more than
one use, otherwise the merge will unexpectedly affect other uses of that
register.
R=ahaas@chromium.org,clemensb@chromium.org
Bug: chromium:1084151
Change-Id: I0d6ad97c585920357a37d95361e0320d32c71f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208851
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67904}
The typed function references proposal allows an optional second
parameter to Table.grow containing the initialization value for the
newly added entries for tables that do not support null defaults.
This CL adds this functionality but hides it behind a newly added
experimental flag --experimental-wasm-typed-funcref.
R=ahaas@chromium.orgCC=jkummerow@chromium.orgCC=manoskouk@chromium.org
Bug: v8:9495
Change-Id: Ia156aeacf95bc36a9fc182990f315c42075cbb7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207184
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67900}
For single-threaded, we can not tier up in the background. Hence we can
either tier up in foreground (which is pointless), or not tier up.
This CL disables Liftoff, so will compile TurboFan code right away.
R=ahaas@chromium.org
Bug: v8:10530
Change-Id: Icfdc26643ab219d617f844c2ea8e149870168dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208853
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67894}
So far this is mainly a readability improvement to specify
expectations on the packed argument. In the future we should also
check signedness during bytecode generation.
Drive-by: Update DCHECK to allow signed args to
CHECK_CURRENT_POSITION.
Bug: chromium:1083450
Change-Id: I9376ec691b51eb251c972309ad65dd6c04eec3ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207137
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67880}
The lowering for anytrue was assuming that the input nodes are all
integers. The regression test added in https://crrev.com/c/2194471 calls
anytrue with float operands, this was causing the lowering to generate
cmpl instructions with a float register and an immediate, which is
wrong.
The fix is to use GetReplacementsWithType on the input nodes, but
only if the input were floats, since we use Word32Equal.
Drive-by clean up of comments in the aforementioned regression test.
Bug: v8:10535
Change-Id: I4de89516c178e9003a4c745808d831be87918381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203400
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67878}
GraphAssembler creates Phi nodes and creates additional inputs to them
depending on how many jumps go there. If the typer decorator is active,
it will type the Phi node at creation time. GraphAssembler was not aware
of types (until recently it was not used while the graph is typed) and
did not update the Phi type with each new input. This CL fixes that.
Bug: chromium:1082704
Change-Id: Id94bcda752c7b3dc836eb2b6c6b55b1690185a09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202978
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67823}
The scheduler could schedule unreachable nodes on two basic blocks that
later merge. Update DCHECK in graph-assembler's basic block updater to
only check for the self-containedness of unreachable basic blocks
removed from the schedule after all the blocks have been re-written to
allow for this case.
BUG=chromium:1079446,v8:9684
Change-Id: I91899dbf389e4425542dbd2b1ca95c3f6ad79c05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196354
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67812}
The --no-wasm-async-compilation disabled async compilation so far, but
async compilation was still possible over streaming compilation. With
this CL, also streaming compilation is disabled.
R=clemensb@chromium.org
Bug: v8:9760
Change-Id: I7e8d4db9e3bb960e8e7380e2190409f63b2f1968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199343
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67807}
The AVX implementation does not have dst == input(0), so the vminps call
was wrong. The intention is to compare the 2 input operands.
Bug: chromium:1081030
Change-Id: Id54074327a6aca4b75988fc9d85beccfeabfc791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194471
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67786}
... when one of the receivers is a JSArray that may have a read-only
length.
Bug: chromium:1069530
Change-Id: Idbaf1a9030bb5a0f9c25e30925f18f603a99832f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2196353
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67783}
We can't attach a meaningful stack trace to the AggregateError
Promise.any rejects with, but we can augment the individual errors'
stack traces with Promise.any and the index of the corresponding
Promise in the input.
Bug: v8:9808
Change-Id: I7ba754c9b043594decaac8b3a23be74f05c3dffd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198983
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67778}
Prior to this CL we still implemented a HasProperty-GetProperty
sequence when accessing named captures in GetSubstitution. This was
briefly part of the spec (we also threw an exception when the property
was not present), but since late 2017 the GetProperty call has been
unconditional.
See https://tc39.es/ecma262/#sec-getsubstitution.
Bug: v8:10513
Change-Id: Id82c06958b0b0feffc6eede580b99ab8676a0dae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2195821
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67733}
... when the element is read-only in one of the prototypes:
* the length should not be updated,
* in strict mode the store operation should throw TypeError.
Bug: chromium:1055138
Change-Id: I7fc08e22c83f8a9848053cfe20851dc1b82f0e3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172090
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67717}
Scripts aren't callable functions. Even though internally they were for a
while, they aren't anymore. We shouldn't return them to users as if they were.
We already remove strict-mode functions from CallSites, so we now do the same
for internal functions that are created for scripts.
Bug: v8:10508
Change-Id: I270c714524439fba9ad90dd29826bed4811ba2b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193716
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67709}
In the existing code we used a register of the UseScratchRegisterScope
for the destination address. However, this register is needed for the
ParallelRegisterMove as well. With this CL we use fixed registers for
the destination address and the offset as well. The CL also changes the
implementation of CalculateActualAddress to allow to set an explicit
register for the result.
R=clemensb@chromium.org
Bug: v8:10108, chromium:1079449
Change-Id: I39c11b9ffa5f3e937ce4820b9991482ad711b4b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2192652
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67702}
This changes the existing implementation that creates an unresolved reference for those cases to look at exactly what scopes are relevant so it can correctly handle catch scopes and avoid re-resolving later.
Variable through with aren't marked as assigning since this information isn't relevant for the with itself; and if the with is passed through, there's no need to mark the outer variable as assigned since it's either initialized or it isn't.
The catch variable is assigned since it is relevant for the catch variable.
The CL uses LookupLocal which wouldn't work for deserialized scopes, but this isn't relevant because 1) eval scopes are declaration scopes, and 2) eval causes all outer variables to be maybe_assigned anyway.
Bug: chromium:1074737
Change-Id: I3febca479ddd1f3c62eae299190b06c0b4cd3746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187272
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67683}
This reverts commit 6204768bab.
Reason for revert: A number of Clusterfuzz reports (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1079474)
Original change's description:
> [turbofan] Improve equality on NumberOrOddball
>
> This CL cleans up CompareOperationFeedback by replacing it with a
> composable set of flags. The interpreter is changed to collect
> more specific feedback for abstract equality, especially if oddballs
> are involved.
>
> TurboFan is changed to construct SpeculativeNumberEqual operator
> instead of the generic JSEqual in many more cases. This change has
> shown a local speedup of a factor of 3-10, because the specific
> operator is way faster than calling into the generic builtin, but
> it also enables additional optimizations, further improving
> runtime performance.
>
> Bug: v8:5660
> Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67645}
TBR=rmcilroy@chromium.org,neis@chromium.org,mythria@chromium.org,nicohartmann@chromium.org
Change-Id: I3410310ed2b1ff2eaee70c1b91c3151d35866108
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190414
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67673}
The code generated by TurboFan was incorrect when comparing to
non-oddball undetectables using abstract equality. In particular,
%GetUndetectable() == %GetUndetectable() did not return false.
Bug: chromium:1051008
Change-Id: Ib62adc72a20aa6cca9ef6499d5fe7429f04623cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187498
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67647}
This CL cleans up CompareOperationFeedback by replacing it with a
composable set of flags. The interpreter is changed to collect
more specific feedback for abstract equality, especially if oddballs
are involved.
TurboFan is changed to construct SpeculativeNumberEqual operator
instead of the generic JSEqual in many more cases. This change has
shown a local speedup of a factor of 3-10, because the specific
operator is way faster than calling into the generic builtin, but
it also enables additional optimizations, further improving
runtime performance.
Bug: v8:5660
Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67645}
After sorting the work array but before writing the values back into
the actual receiver, we have an accessor check. This accessor check
needs to be stricter, in order to catch Array prototype protector
cell invalidations.
R=jgruber@chromium.org
Bug: chromium:1077508
Change-Id: I3c3bd4711f9019f9d4423701724319eee9d800a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187171
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67638}
On the PredictablePlatform, worker tasks were executed immediately
instead of posting them in a task queue first. This approach caused
problems because the execution of the worker task blocked progress of
the posting task, and the worker task was always executed in the
context of the posting task, e.g. with an already open HandleScope.
With this CL, worker tasks get posted into the foreground task queue
of the nullptr isolate instead of executing them immediately.
The tasks of the nullptr isolate are then executed after a task of
some other task queue is executed. As the worker tasks are thereby
executed on the same thread as foreground tasks, the behavior is
deterministic.
A consequence of this approach is that each pumping the message loop
of an Isolate may also execute other Isolate's background tasks.
This approach is needed because we don't have a BackgroundTaskRunner but
merely a CallOnWorkerThread method that doesn't know which Isolate the
task corresponds to.
R=clemensb@chromium.org, mlippautz@chromium.org
Bug: v8:9670
Change-Id: I6847ae042146431bc2376d27280be8829f529b95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182453
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67616}
Motivation:
There were three versions of type decoding for wasm in the codebase.
Not all of them decoded gc types with immediates (reference types)
correctly.
Changes:
- Refactor the wasm binary decoder for unify type decoding.
- Update BranchTypeImmediate and SelectTypeImmediate to handle
reference types.
Reference: https://github.com/WebAssembly/gcR=jkummerow@chromium.org
Bug: v8:7748
Change-Id: I33b38c911d366570ca6ef2723ded5205698e1979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179003
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67614}
When the input to a speculative BigInt operation was an undefined
constant, no necessary type check was inserted by the
RepresentationChanger. This CL fixes this.
Bug: chromium:1077804
Change-Id: I3d4e15b1e018803d56e46c7b23b9d4b03832ba8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182455
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67610}
Upon deserialization, serialized references to the global proxy are
replaced by the actual global proxy object. We must do the same for
the global proxy map.
Drive-by: Updated other outdated test skips.
Bug: v8:10504,v8:10416
Change-Id: Ib47ae2d08bbea2ca916f53152e9d4f75bb0a0e15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183913
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67596}
The serializer currently cannot handle a heap state containing
arbitrary compiled Code objects. As a quick fix for the
--stress-snapshot d8 flag, we clear compiled data from the isolate
prior to the serialize-deserialize-verify pass.
With this change, mjsunit tests pass on x64.
The %SerializeDeserializeNow() runtime function would require more
work, since it is not possible to mutate the heap to this extent while
still preserving a runnable host context and isolate. We will need
another solution there.
Drive-by: Skip the stress_snapshot variant except for the mjsunit
suite.
Tbr: machenbach@chromium.org
Bug: v8:10493,v8:10416
Change-Id: Ie110da8b51613fcd69c7f391d3cf8589d6b04dd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182429
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67585}
... to be in sync with KeyedLoadIC_SloppyArguments in handling OOB
accesses which may involve prototype chain walk.
Bug: chromium:1063796
Change-Id: I8421c19085dfd2f3b6360c64fd04f53b1351576c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2174504
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67541}
This variant passes the --stress-snapshot d8 flag. There's a large
initial list of skips, these should be removed as issues are fixed
over time. The variant is currently not enabled on any bots.
Bug: v8:10416
Change-Id: I80aea80600c51b2f5d28b8ec8a09ff0ba2ebaa7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179002
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67536}
- Update opcode numbers, tests
- As the wasm-module-builder currently assumes opcode bytes, skip
the test that needs a multi-byte leb128 opcode
- Renumber post-MVP opcodes
Change-Id: I6531e954e63986dc6f7a3144ec054d16e6dc1b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67517}
Spilling a register in Liftoff require a scratch register when the
offset of the stack slot from fp is greater than 2^12. This CL adds
a check to LiftoffAssembler::Spill on arm to check that a scratch
register is available. It also fixes one case where the scratch register
was not available.
R=clemensb@chromium.orgCC=zhin@chromium.org
Bug: chromium:1075953
Change-Id: Idb2bc7e26e3d4fbd6bb0eb6c9a9b8cfd8b3c569e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172424
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67494}
The interpreter will be un-shipped soon, hence we cannot have a
compilation hint for interpreted execution.
This CL removes the respective enum value, removes a test which
specifically tested this one option, and adapts other code to use one of
the remaining hints.
R=ahaas@chromium.org
Bug: v8:10389
Change-Id: Ia754f7de95be271000a9e4e10ef2a3ee171da627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172748
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67491}
With this CL the registers in a register pair get ordered such that the
low word register always has a lower register code than the high word
register. This should allow easier reasoning about the register
allocation, and prevent some register allocation bugs.
Background: for many operations in Liftoff, input registers are reused
as output registers. With register pairs, input register pairs are
reused as output register pairs. Additional reasoning, and sometimes
even additional code is needed when the registers of the output register
pair are swapped, i.e. when the high word register of the input becomes
the low word register of the output. With this CL the additional
reasoning is not necessary anymore, as the high word and low word
registers would get swapped during register allocation.
Additionally this CL fixes the logic of the last_spilled_regs list. This
list stored the last spilled registers, but recorded only one of the two
registers of a register pair. With this CL, both registers get recorded.
This CL does not have a regression test. The regression test was more
than 9000 lines long, and quite slow. I was not able to minimize it
substantially. The test would be fragile by nature, as it has to create
a special register configuration or otherwise does not test anything
meaningful. All in all I think it's better not to add the test.
R=clemensb@chromium.org
Bug: chromium:1074586
Change-Id: I4b2475b0c6537c7ce2e51fee281388cdd85f2953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168875
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67473}
To reduce the number of deoptimizations in TurboProp use call feedback
only when we know the call target is a builtin. Given that we don't
inline in TurboProp, call feedback isn't really useful and using Generic
lowering doesn't impact performance much. TurboProp still inlines
builtins, so it is important to use this feedback for generating better
optimized code.
BUG: v8:10431
Change-Id: I24d51e43728f9aea3099767deb7800119fea40e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116033
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67468}
Since ES6, optional arguments are treated the same as undefined. This
was recently cleaned up in https://github.com/tc39/ecma262/pull/1411.
The current Torque implementation of %TypedArray%.from incorrectly
interpreted the old (and confusing) language of a parameter being "not
present" as testing using arguments.length instead of testing directly
for undefined.
Bug: v8:10458
Change-Id: I055f1fa3be570a31a4f7369ba5b51b7d6b022f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168674
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67454}
Having no value argument in DataView setters (e.g. setFloat64) caused
wrong behavior in compiled code.
Bug: chromium:1071190
Change-Id: I37ddba8555dafad321f8d4c1352da8a501a98453
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170091
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67451}
In AtomicOp64 ClearRegister is called twice to clear the registers r8
and r9. Thereby new registers may get allocated. We forgot to add the
newly allocated registers to pinned after the first call to
ClearRegister, which caused the same registers to be allocated again in
the second ClearRegister, and thereby caused the bug.
R=clemensb@chromium.org
Change-Id: I0d069aea4c9438fe30c30c22406b4075ddf3e95c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170088
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67445}
... by making sure we deopt when the buffer is detached.
Bug: chromium:1074736
Change-Id: I86e4e63014767766d7c079c3a3e38d947c76ef10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168874
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67437}
This removes the {RedirectToWasmInterpreter} runtime function and the
respective method from {WasmDebugInfo}.
Some tests test specifically the interaction between compiled code and
the interpreter. They are irrelevant now and are deleted.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I38330fcb523f7c65968fdf03abc60af3392bdcc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164793
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67427}
This is a reland of ad5b005e38
Original change's description:
> [snapshot] Expose the serializer through %SerializeDeserializeNow
>
> ... in order to exercise the snapshot/ component from mjsunit tests
> and fuzzers.
>
> * Since the serializer and deserializer can now be called at any time
> instead of only in a tightly controlled environment, several
> assumptions (such as an empty execution stack, no microtasks, no
> handles) no longer hold and had to be made configurable through
> SerializerFlags.
>
> * Root iteration now skips more root categories which were previously
> guaranteed to be empty (e.g. the stack, microtask queue, handles).
>
> * The %SerializeDeserializeNow runtime function triggers
> serialization, deserialization, and heap verification on the current
> isolate and native context.
>
> Support is not yet complete and will be extended in future work. Once
> all mjsunit tests successfully run, we can add a new test mode to
> stress serialization.
>
> Bug: v8:10416
> Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67423}
Tbr: delphick@chromium.org,ulan@chromium.org
Bug: v8:10416
Change-Id: Ibed04c0f0b72fabcf811d8b18a1479391a11568b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170090
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67426}
This reverts commit ad5b005e38.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/36070?
Original change's description:
> [snapshot] Expose the serializer through %SerializeDeserializeNow
>
> ... in order to exercise the snapshot/ component from mjsunit tests
> and fuzzers.
>
> * Since the serializer and deserializer can now be called at any time
> instead of only in a tightly controlled environment, several
> assumptions (such as an empty execution stack, no microtasks, no
> handles) no longer hold and had to be made configurable through
> SerializerFlags.
>
> * Root iteration now skips more root categories which were previously
> guaranteed to be empty (e.g. the stack, microtask queue, handles).
>
> * The %SerializeDeserializeNow runtime function triggers
> serialization, deserialization, and heap verification on the current
> isolate and native context.
>
> Support is not yet complete and will be extended in future work. Once
> all mjsunit tests successfully run, we can add a new test mode to
> stress serialization.
>
> Bug: v8:10416
> Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67423}
TBR=ulan@chromium.org,jgruber@chromium.org,delphick@chromium.org
Change-Id: Ie30b94c9ec6e4463bed6cc87dd6525f469fdf84a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170089
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67424}
... in order to exercise the snapshot/ component from mjsunit tests
and fuzzers.
* Since the serializer and deserializer can now be called at any time
instead of only in a tightly controlled environment, several
assumptions (such as an empty execution stack, no microtasks, no
handles) no longer hold and had to be made configurable through
SerializerFlags.
* Root iteration now skips more root categories which were previously
guaranteed to be empty (e.g. the stack, microtask queue, handles).
* The %SerializeDeserializeNow runtime function triggers
serialization, deserialization, and heap verification on the current
isolate and native context.
Support is not yet complete and will be extended in future work. Once
all mjsunit tests successfully run, we can add a new test mode to
stress serialization.
Bug: v8:10416
Change-Id: Ie7ff441a761257dd7f256d0a33e73227850074ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159495
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67423}
The interpreter will be moved to be test-only, hence
--wasm-interpret-all also needs to be removed.
Since we don't have any non-compiling tier any more, we also remove the
implication from --jitless to --wasm-lazy-compilation. Instead, we add
another CHECK that we can't be in jitless mode if we trigger any wasm
compilation.
All tests that just ran other tests and additionally passed
--wasm-interpret-all become redundant and are deleted. Also all
regression tests that explicitly specify --wasm-interpret-all are not
needed any more.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I5ddf20a842117a6c05e277a5308f5cfe42e6bfa5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164792
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67419}
PerformPromiseAll doesn't set iteratorRecord.[[Done]] to true if
Promise.resolve is not callable. This makes Promise.all call
IteratorClose.
BUG=v8:10452
Change-Id: Icbe17416a733f68ef09f1c610d715f544c2a3b8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2164789
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67416}
This reverts the changes made in
https://chromium-review.googlesource.com/c/v8/v8/+/1695465https://chromium-review.googlesource.com/c/v8/v8/+/1776078
We originally moved this protector to the native context to avoid
cross-native-context pollution of protector state. Ideally,
invalidating a protector in one NC should not affect any other NC.
But as it turns out, having the protector on the NC causes more
problems than it solves since all affected callers now need to find
the correct native context to check. Sometimes (e.g. in CSA regexp
builtins) it is possible to blindly check the current NC, but the
reasoning behind this optimization is tricky to understand.
Sometimes, fetching the correct NC is not possible due to access
restrictions. These implementation complexities outweigh the (unknown)
potential performance benefits.
In the future we should attempt to move away from the protector
concept for these kinds of checks.
Bug: chromium:1069964,v8:9463
Change-Id: I2cbb2ec7266282165dae5e4a6c8bdbda520c50a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157382
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67415}
Extend the flag parameter with a bit that decides if the input should
be converted (-0 to 0, and a string to the array index it represents).
Instruct redundancy elimination to never replace x with CheckBounds(x)
when this CheckBounds is of the converting kind.
Bug: chromium:1070892, chromium:1071743
Change-Id: I3125a6e267d56dae6bf6cb2f5f52d27ef65d7c79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157365
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67408}
This relands commit 1a38573f9d.
The original change used a sequence of instruction in the test that
could not be scalar lowered properly.
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
Bug: chromium:1070078
Change-Id: I02bb4b3ad03817318cbd0ee706c5ef4f20c845ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165867
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67406}
This patch has the following improvement on v8.browsing_mobile:
- total-main-thread:duration improved by 1.7%
- js:duration improved by 1.3%
Change-Id: I1cdf2c181bfd991b67f31c5c2f32e3c2f909c67e
Bug: v8:9684, v8:10431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149433
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67405}
This adds a test which I suspected would fail, but luckily it doesn't.
The idea is to catch a proper wasm exception in JS, then construct a new
exception, but set the catched exception as the prototype. My suspicion
was that we would still handle that new exception like a wasm exception,
since the `WasmExceptionGetTag` and `WasmExceptionGetValues` runtime
functions to a standard property lookup, which includes a prototype
walk.
Interestingly, the prototype walk is already skipped automatically when
loading private symbols, so the implementation already supports this
case correctly.
Let's still add this test to have coverage for this case.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:8091
Change-Id: Idf9944cf47f96cca38e9678e9200bf03a39ea126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2167438
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67391}
This reverts commit 390ed4b934.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36714?
Original change's description:
> [arm] Change fp_fixed registers to be allocatable registers
>
> fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
> need to be allocatable, so that they can be correctly marked as fixed
> and spilled as required. The previous value of fp_fixed2, d29, is not in
> the list of allocatable double registers, and not marked as fixed
> appropriately.
>
> One fix could be to extend the list of allocatable double registers, but
> there is a comment there saying that the list is kept even-length to
> make stack alignment easier. So rather than messing with that, we
> instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
> the only user, this is a simpler change.
>
> Bug: chromium:1070078
> Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67372}
TBR=gdeepti@chromium.org,zhin@chromium.org,thibaudm@chromium.org
Change-Id: I00b4b34771b5832cc3d5fe6eac7aac506ec82d50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1070078
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165865
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67375}
fp_fixed1 and fp_fixed2 are used by the S8x16Shuffle operation. They
need to be allocatable, so that they can be correctly marked as fixed
and spilled as required. The previous value of fp_fixed2, d29, is not in
the list of allocatable double registers, and not marked as fixed
appropriately.
One fix could be to extend the list of allocatable double registers, but
there is a comment there saying that the list is kept even-length to
make stack alignment easier. So rather than messing with that, we
instead change what fp_fixed1 and fp_fixed2 is, since S8x16Shuffle is
the only user, this is a simpler change.
Bug: chromium:1070078
Change-Id: Id7de9b256bad2cfb11b0f06b66eb80a48ff7827c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161565
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67372}
If module bytes end in a prefix like 0xfc (numeric prefix), we read out
of bounds (pc + 1). So, if validate flag is set, check the length.
Bug: chromium:1073553
Change-Id: Ia9771419d01f2315723d19dd96630172b5a7a1f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161404
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67370}
This is a reland of 29c1eab92e
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
Bug: chromium:793406
Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
Cq-Include-Trybots: luci.chromium.try:linux-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
Auto-Submit: Timothy Gu <timothygu@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67361}
This reverts commit 29c1eab92e.
Reason for revert: Causes Blink test failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
Original change's description:
> [builtins] Clean up the use of class_name / ES5 [[Class]]
>
> Before ES2015, the ES spec had a [[Class]] internal slot for all
> objects, which Object.prototype.toString() would use to figure the
> returned string. Post-ES2015, the [[Class]] slot was removed in spec for
> all objects, with the @@toStringTag well-known symbol the proper way to
> change Object.prototype.toString() output.
>
> At the time, spec-identical handling without the use of [[Class]] was
> implemented in V8 for all objects other than API objects, where issues
> with the Web IDL spec [1] prevented Blink, and hence V8, to totally
> migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
> @@toStringTag on API class prototypes to manage the
> Object.prototype.toString() output, so the legacy [[Class]] handling in
> V8 has not been necessary for the past couple of years.
>
> This CL removes the remaining legacy [[Class]] handling in
> Object.prototype.toString(), JSReceiver::class_name(), and
> GetConstructorName(). However, it does not remove the class_name field
> in FunctionTemplateInfo, as it is still used for the `name` property of
> created functions.
>
> This CL also cleans up other places in the codebase that still reference
> [[Class]].
>
> This change should have minimal impact on web-compatibility. For the
> change to be observable, a script must do one of the following:
>
> 1. delete APIConstructor.prototype[Symbol.toStringTag];
> 2. Object.setPrototypeOf(apiObject, somethingElse);
>
> Before this CL, these changes will not change the apiObject.toString()
> output. But after this CL, they will make apiObject.toString() show
> "[object Object]" (in the first case) or the @@toStringTag of the other
> prototype (in the latter case).
>
> However, both are deemed unlikely. @@toStringTag is not well-known
> feature of JavaScript, nor does it get tampered much on API
> constructors. In the second case, setting the prototype of an API object
> would effectly render the object useless, as all its methods (including
> property getters/setters) would no longer be accessible.
>
> Currently, @@toStringTag-based API object branding is not yet
> implemented by other browsers. This V8 bug in particular has been an
> impediment to standardizing toString behavior. Fixing this bug will
> unblock [3] and lead to a better Web IDL spec, and better toString()
> compatibility for all.
>
> [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
> [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
> [3]: https://github.com/heycam/webidl/pull/357
>
> Bug: chromium:793406
> Cq-Include-Trybots: luci.chromium.try:linux-rel
> Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67327}
TBR=verwaest@chromium.org,timothygu@chromium.org
Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67349}
Before ES2015, the ES spec had a [[Class]] internal slot for all
objects, which Object.prototype.toString() would use to figure the
returned string. Post-ES2015, the [[Class]] slot was removed in spec for
all objects, with the @@toStringTag well-known symbol the proper way to
change Object.prototype.toString() output.
At the time, spec-identical handling without the use of [[Class]] was
implemented in V8 for all objects other than API objects, where issues
with the Web IDL spec [1] prevented Blink, and hence V8, to totally
migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
@@toStringTag on API class prototypes to manage the
Object.prototype.toString() output, so the legacy [[Class]] handling in
V8 has not been necessary for the past couple of years.
This CL removes the remaining legacy [[Class]] handling in
Object.prototype.toString(), JSReceiver::class_name(), and
GetConstructorName(). However, it does not remove the class_name field
in FunctionTemplateInfo, as it is still used for the `name` property of
created functions.
This CL also cleans up other places in the codebase that still reference
[[Class]].
This change should have minimal impact on web-compatibility. For the
change to be observable, a script must do one of the following:
1. delete APIConstructor.prototype[Symbol.toStringTag];
2. Object.setPrototypeOf(apiObject, somethingElse);
Before this CL, these changes will not change the apiObject.toString()
output. But after this CL, they will make apiObject.toString() show
"[object Object]" (in the first case) or the @@toStringTag of the other
prototype (in the latter case).
However, both are deemed unlikely. @@toStringTag is not well-known
feature of JavaScript, nor does it get tampered much on API
constructors. In the second case, setting the prototype of an API object
would effectly render the object useless, as all its methods (including
property getters/setters) would no longer be accessible.
Currently, @@toStringTag-based API object branding is not yet
implemented by other browsers. This V8 bug in particular has been an
impediment to standardizing toString behavior. Fixing this bug will
unblock [3] and lead to a better Web IDL spec, and better toString()
compatibility for all.
[1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
[2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
[3]: https://github.com/heycam/webidl/pull/357
Bug: chromium:793406
Cq-Include-Trybots: luci.chromium.try:linux-rel
Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67327}
There's no reason for it to be a JSArray; it's an internal data member.
We only have a slow version for constructing a FixedArray from an
Iterable, but since this is not a performance critical code path,
it's fine.
BUG=v8:9808
Change-Id: I5bcfac4cc545880966421a96d3aa3d899bbf6cd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157371
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67321}
This is a reland of 80843eda31
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
Bug: v8:7793
Change-Id: I783b6ec080042fec0e922927f6675dede458a072
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159731
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67305}
This reverts commit 80843eda31.
Reason for revert: Causes compilation failure on macs
https://ci.chromium.org/p/v8/builders/ci/Mac%20V8%20FYI%20Release%20(Intel)/8934?
Original change's description:
> [torque] Allow storing to bitfield structs that are stored in Smis
>
> This change:
> 1. Updates the Torque compiler to allow direct access to bitfields that
> are packed within Smi values, which previously would have required a
> separate untagging step,
> 2. Updates JSRegExpStringIterator to represent its flags in Torque,
> 3. Adds reduction cases in MachineOperatorReducer for when the input to
> a branch or the left-hand side of a Word32Equals is based on a 64-bit
> shift-and-mask operation which has been truncated to 32 bits, as is
> the case in the code generated by step 1, and
> 4. Adds a reduction case in MachineOperatorReducer to remove an extra
> Word64And operation added by step 1.
>
> Bug: v8:7793
> Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67290}
TBR=tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org
Change-Id: Ifa683c92631291c9437438682b6efb2e12862682
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159730
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67291}
This change:
1. Updates the Torque compiler to allow direct access to bitfields that
are packed within Smi values, which previously would have required a
separate untagging step,
2. Updates JSRegExpStringIterator to represent its flags in Torque,
3. Adds reduction cases in MachineOperatorReducer for when the input to
a branch or the left-hand side of a Word32Equals is based on a 64-bit
shift-and-mask operation which has been truncated to 32 bits, as is
the case in the code generated by step 1, and
4. Adds a reduction case in MachineOperatorReducer to remove an extra
Word64And operation added by step 1.
Bug: v8:7793
Change-Id: Ib4ac2def6211b3cae6be25a8b2a644be5c7d6d3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2119225
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67290}
We give the optimized code another chance on soft deopts in TurboProp.
If the deopt is happening on infrequently taken paths, then this will
let us reuse the optimized code for the subsequent executions. If the
soft deopts are happening multiple times on the same code, then we would
discard the optimized code. The number of deopts we would wait is
controlled by FLAG_reuse_opt_code_count.
BUG=v8:10433
Change-Id: Iaadea4cffde7d7d55be4875c9586694dca64957c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093503
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67289}
This reverts commit f442b03fe2.
Reason for reland: Wrongly reverted.
Original change's description:
> Revert "[turbofan] Fix bug in Number.Min/Max typings"
>
> This reverts commit 4158af83db.
>
> Reason for revert: causing UBSAN failures:
>
> https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
>
>
> Original change's description:
> > [turbofan] Fix bug in Number.Min/Max typings
> >
> > They try to be very precise about when the result can be -0,
> > but do so incorrectly. I'm changing the code to just do the
> > simple thing instead. Let's see how that affects performance.
> >
> > Bug: chromium:1072171
> > Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#67246}
>
> TBR=neis@chromium.org,tebbi@chromium.org
>
> Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1072171
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
> Reviewed-by: Francis McCabe <fgm@chromium.org>
> Commit-Queue: Francis McCabe <fgm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67249}
TBR=neis@chromium.org,tebbi@chromium.org,fgm@chromium.org
Change-Id: Ida36ca584a5af5da887189328c8da195b26285d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157368
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67263}
This reverts commit 4158af83db.
Reason for revert: causing UBSAN failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729?
Original change's description:
> [turbofan] Fix bug in Number.Min/Max typings
>
> They try to be very precise about when the result can be -0,
> but do so incorrectly. I'm changing the code to just do the
> simple thing instead. Let's see how that affects performance.
>
> Bug: chromium:1072171
> Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67246}
TBR=neis@chromium.org,tebbi@chromium.org
Change-Id: I0d9b312e27f5a8bbbebeccdc9819fa94f10af139
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1072171
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157646
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67249}
They try to be very precise about when the result can be -0,
but do so incorrectly. I'm changing the code to just do the
simple thing instead. Let's see how that affects performance.
Bug: chromium:1072171
Change-Id: I9737a84aa19d06685af5b7bca541e348dc37cca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157028
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67246}
The fast store handlers create elements and if we have a typed array
on the prototype chain it is not easy to check when it is OK to create
new elements. The TypedArrays swallow all OOB stores, and there is no
easy way to check if the current store is OOB for JSObjects. So use
slow stub when there are typed arrays on the prorotype chain of
JSObjects.
Bug: chromium:1068492
Change-Id: I9eea9cf00e3eb84931c5545d18ba53c4ec39f353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134138
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67226}
A new realm doesn't contain the mocks and suppressions on the global
object for correctness fuzzing. We replace Realm.eval with eval to
keep exercising the code.
Bug: chromium:1071133
Change-Id: Iffe82d37bf08829fc5937c17c2089277403e71dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153206
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67187}
SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.
In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.
There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.
Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67186}
When we create a new elements array we should initialize it with holes.
The capacity of the newly created elements array could be greater than
the actual length of the array and we expect the unused slots to be
filled with holes.
Bug: chromium:1070560
Change-Id: Ia365eed59859e36a9c8b9e27be34f93ab88942bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150599
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67180}
Change-Id: Ic5dbf4c3330c71cbae73aa07b2adb1c8ac087182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151348
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67172}
Soft-deopt for mono/polymorphic property accesses that don't have any
maps, and only allow zero-map feedback to be monomorphic. This makes
sure we only emit a megamorphic LoadIC builtin call if the IC was
actually megamorphic.
JSGenericLowering assumed that zero maps meant that a load site is
megamorphic. However, it can be the case that the call-site is
monomorphic or polymorphic, and the maps had died. In this case we don't
want to call the megamorphic IC builtin, as on a stub cache miss we
fallback to a normal LoadIC miss, which can record mono/polymorphic
feedback in the IC. After this, we'll enter a miss loop in the
megamorphic load builtin, and worse the LoadIC assumes that there's
something "wrong" with the feedback, so it'll keep trying to reconfigure
the handler (possibly allocating new load handlers if this is a
prototype field access).
As a drive-by, rewrite GetRelevantReceiverMaps to be an in-place
filtering of the maps rather than copying them.
Change-Id: I0c25bfa606367fa81c43223bbd56cdadb5e789ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150586
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67152}
In strict mode stores to non-existent properties throw. We should not
install a handler with the property cell for such stores. These handlers
would expect that the value exists when they see a property cell. If
this property cell gets invalidated later, it appears as if it is a
valid property cell with undefined value. This leads to an incorrect
behaviour. This cl checks if we are in strict mode and uses a slow
stub in such cases.
Bug: chromium:1067757
Change-Id: I543c6a6931530bfb13cc9a33d1dabaa756489fd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2142255
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67151}
Bug: chromium:1070890
Change-Id: I62ad81b8d5bcb9934c7eda4eae595d41339adfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2149425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67147}
When memory.grow was executed concurrently on multiple threads a data
race could happen such that two memory.grow operations result in the
same return value. With this CL the return value of memory.grow is
unique, given that memory.grow actually grows the memory.
As a concrete example, assume a shared WebAssembly memory initially has
a size of 100. Assume two threads call memory.grow concurrently with a
parameter `10`. Then with the existing code, memory would grow correctly
to a size of 120, but the data race may cause both memory.grow
operations to return 100. With the change in this CL one memory.grow
operation would return 100, the other would return 110.
R=gdeepti@chromium.orgCC=rreverser@google.com
Bug: chromium:1067621
Change-Id: Ib22b5135714a56799e0818ccb39e5dce327e5f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144113
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67135}
For example, when --fuzzing is off, %OptimizeFunctionOnNextCall now
crashes when given a non-function argument.
The following behaviors remain unchanged for now:
- %DeoptimizeFunction continues to do nothing if the function is not
optimized.
- %DeoptimizeNow continues to do nothing if the top-most JS function
is not optimized.
- %OptimizeOSR continues to do nothing if the function already has
optimized code.
Bug: v8:10249
Change-Id: I35d2f3d50ce3f94c8ffccabe50fb4df2b70ce028
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137406
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67121}
This is a reland of f902ef3257
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
Bug: v8:10349
Change-Id: I38c8b6beb07a1e5d565c6a5fd749daea147817bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144064
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67087}
This reverts commit f902ef3257.
Reason for revert: Makes gc-stress unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/27404
Original change's description:
> [wasm] Cleanup wasm script creation
>
> - Do not expose CreateWasmScript since we should now use
> WasmEngine:GetOrCreateScript instead,
> - Initialize all Script fields in CreateWasmScript, not in
> WasmModuleObject::New,
> - Do not pass code size estimate argument, since we can always use the
> actual native module's committed code space.
>
> R=clemensb@chromium.org
>
> Bug: v8:10349
> Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67083}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: Iac2978af1a300ec079baebab0feb8c9598711738
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144058
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67085}
- Do not expose CreateWasmScript since we should now use
WasmEngine:GetOrCreateScript instead,
- Initialize all Script fields in CreateWasmScript, not in
WasmModuleObject::New,
- Do not pass code size estimate argument, since we can always use the
actual native module's committed code space.
R=clemensb@chromium.org
Bug: v8:10349
Change-Id: If9250d62ffc271ab6efc3b9c45958a305c9d1827
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135633
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67083}
Apple currently objects to cleanupSome but agrees to shipping the rest
of WeakRefs. Separate out cleanupSome to its own flag so the rest of
WeakRefs may ship.
Bug: v8:8179
Change-Id: I6159fc743c9cb658860d4260b0dcb95e54630fdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2141011
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67070}
JSNativeContextSpecialization lowered this operator to a regular
property store, potentially ignoring a request to set the "name"
property of a function.
This CL performs the lowering only if there's no such request.
Bug: chromium:1068494
Change-Id: Ia2eaf05af9c8402f9e6450ee519a7c36c18cd44e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139581
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67058}
This relands commit 7d955faa76.
Changed the test case to use i16x8 splat instead of i8x16 splat,
the latter was causing issues when doing scalar lowering. This
change still causes the regression test to fail without the fix.
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
Bug: chromium:1065599
Change-Id: I0dc78ddb013652ef88c07d065c3f6877937c5300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2136220
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67026}
This is a minimal version of https://crrev.com/c/2135642 intended for
backmerges.
Ensure that the interpreter has space for all required registers.
Bug: chromium:1067270
Change-Id: Iefd016b4845fb8698d1e0ef5f6a03df0e66aa576
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67013}
Typed array iteration throws a TypeError if the receiver is not
a typed array. The JSCallReducer didn't take that into account.
Bug: chromium:1067544
Change-Id: Ib065ba1b7881dc0b62242fc416fa16023a7fa244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135632
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67010}
This reverts commit 7d955faa76.
Reason for revert: Bad change, modified wrong test file https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36416
Original change's description:
> [wasm-simd][x64][ia32] Do not overwrite input register
>
> We are ovewriting input register (contains the shift) when we are
> masking it, instead, move to a temporary,then mask it.
>
> Bug: chromium:1065599
> Change-Id: Iab72b94581239447e444746681387350b576e24a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66997}
TBR=gdeepti@chromium.org,zhin@chromium.org
Change-Id: I50c57906d6eb49758584b477c971179ea3c6e5d3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1065599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2134655
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67000}
We are ovewriting input register (contains the shift) when we are
masking it, instead, move to a temporary,then mask it.
Bug: chromium:1065599
Change-Id: Iab72b94581239447e444746681387350b576e24a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2125941
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66997}
For keyed stores we recompute handlers based on the receiver maps
we have seen. This is done so that we can transition to the most generic
elements kind we have seen so far. When we recompute this handlers we
get a new prototype validity cell and ignore the existing cell. This
leads to incorrect behaviour if the cell was invalid. Recomputing the
handler may be extra work which is not worth doing at this point. So
we just reuse the existing validity cell and let the IC recompute the
handler if we see the map again.
Bug: chromium:1053939
Change-Id: Ifc891d70f5a4b8b774238e12fb40e29b4d174e37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122032
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66963}
Double literals without dots should still be parsed as double constants,
not unsigned constants. The static_cast would remove the fractional
part, making constants like "1e-15" come out as "0" unsigned constants.
The precise semantics is not spec'ed, so we still consider literals like
"1e1" to be unsigned, and only switch to double if there is a fractional
part.
R=ecmziegler@chromium.org
Bug: chromium:1065635
Change-Id: I0aac018058a149632e0849572d19fdcc7b2af7aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126922
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66949}
The ReduceStringPrototypeStartsWith implementation in TurboFan
was doing the CheckString too late, after returning "false" in
case there are no arguments.
Fixed: chromium:1065741
Change-Id: I1016383d65120d3b050e76d6ac41986497af0b8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2129639
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66948}
JSStoreGlobal can become a call into runtime code (SetProperty)
that inspects the context in order to get the language mode. Thus
always passing the native context is not good enough.
Bug: chromium:1065737
Change-Id: Iba9537cd3de743a0967325acf7900190aa835b5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130280
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66946}
If "use asm" is used inside a "function*" or async function, it should
bail out.
Drive-by: Minor cleanup in {Runtime_InstantiateAsmJs}.
R=ecmziegler@chromium.org
Bug: chromium:1065852
Change-Id: Ice48126b803a30c4b4ff7b5ae22df85a3f36198a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126920
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66939}
If we want external people to stop shouting WASM, we should start
by avoiding that in our own code base.
This CL replaces almost all occurrences of "WASM" by "Wasm". The
last remaining ones (in frames.cc) are in capitalized contexts where
WASM fits.
TBR=ecmziegler@chromium.org
Bug: v8:10155
Change-Id: I905b92220768b99bb5e1165255691ffe4498dba3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126917
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66917}
Rework the remaining tests in grow-memory to check for first 5 offsets
and last 5 offsets in the relevant pages.
Bug: v8:7783
Change-Id: I59435f3c1a6f50ff808fdd045a6c7039860fc72e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116647
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66896}
The asm-wasm-f32 and asm-wasm-f64 tests run through a bunch of different
constants. For the binops, they run through a cross product of the
inputs. This patch trims down the number of constants used.
The selection of constants to remove is quite arbitrary - the intial
patch introduced a lot of magic constants that look random or has some
pattern. I don't think they mean anything special, especially for f64
form since those values all fit in a f64. For f32 we still have a bunch
of values to exceed the maximum integer representable in f32.
Bug: v8:7783
Change-Id: If34b084a11acdf21b1d2933fdd0cab65be1738c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116988
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66882}
Yet another corner case how non-deterministic timestamps slipped into
the tests.
Bug: chromium:1064900
Change-Id: I33e8b4c8141b3854b7eca5d7ad9b45b6f5130d9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120584
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66881}
Rework testMemoryGrowPreservesDataMemOp tests so that they only test the
first and last 5 offsets within the page, instead of every offset.
Slight logic change: instead of storing the value C - offset (where C is
a constant that is different for 32 and 16 memops), we store just the
value offset. This allows us to combine the logic for all 3 memops (32,
16, and 8). But we need to add a modulo so that in the 8 bit case, we
don't store a value that exceeds the maximum (the other cases will never
hit a case that exceeds the max).
Bug: v8:7783
Change-Id: Ibfdc77555ba2ca26391eba303050a03538f6012d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117633
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66879}
For some input types containing -0 but not +0, the result type of
NumberMin and NumberMax would unnecessarily include +0. However, for
some larger inputs, the result type would not include the spurious +0,
thus breaking monotonicity.
The CL fixes this and addresses a TODO as well.
Bug: chromium:1063661
Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66854}
Rework the testMemoryGrowReadWrite and testMemoryGrowZeroInitialSize
tests. Combine the different sized tests (32, 16, 8 bit integers) into a
single base tests, taking in function arguments to specify which
load/store function to call from the module exports.
Also reduced the number of checks made in each test. Previously the test
was asserting on every single valid offset. Now it checks the first 5
and the last 5 of each page of memory. From a quick local test using
`time`, it speeds up this test on x64 from ~40s to ~20s.
There is more work to be done: there are other tests below that also
assert on each offset, we can change those in a future patch.
The goal is to be able to run this on arm simulators
sufficiently quickly, and not require to mark this test as slow.
Bug: v8:7783
Change-Id: I2b17cf1811de6c26332d7e8f91efbbac3e89f6e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116601
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66848}
This might help reduce flaky test results caused by too high memory
consumption due to the large Float32Array in regress-crbug-1057653.js.
Bug: v8:10333
Change-Id: Id99ebb67ebe5a7a730e44cd8967ebbea905ccdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108547
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66836}
The behaviour was clarified in the spec:
https://github.com/WebAssembly/exception-handling/pull/97
br_on_exn (and also rethrow, which will be added in another CL) should
trap on nullptr. This CL implements this by an explicit check on each
br_on_exn (within {GetExceptionTag}). This check will be redundant if
several br_on_exn follow each other. Since also the runtime call for
{GetExceptionTag} is redundant, and also the fact that we do a runtime
call is suboptimal, I consider the whole implementation prototypical for
now anyway.
R=jkummerow@chromium.orgCC=aheejin@chromium.org
Bug: v8:10128
Change-Id: I234c3183f93fe0884aadd2ab6dbd6c2b7a07c660
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2113381
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66826}
I'm unable to produce an issue with this test locally, so let's
try to enable it again.
Big: v8:6587
Change-Id: Ida834ac4ccf8c25d8f5c1e09fc57479db46a1873
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108722
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66803}
This is a reland of 2c834c5364,
in which node replacement was too aggressive.
Original change's description:
> [turbofan] Clean up ConstantFoldingReducer
>
> Change-Id: Iaf7f83cc157a6f6680da8933560347f7f3503d56
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2098736
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66706}
Change-Id: I5d306092dde4119629af4c5e7e424a0e9a14310d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106193
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66742}
to properly choose named or indexed mode
Bug: chromium:1059738
Change-Id: Icd086fee31079f52770742afa54fc946acb1fd81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2101005
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66702}
When dst is a fp pair, we set both low and high fp regs. Later when we
look at set regs to determine which registers to load into, we examine
both low and high fp. This is wrong - we only need to look at the low
fp, since Fill will load into the correct fp pairs. The bug was
triggered because we were examining into junk values in register_loads
indexed by the high fp.
Fixed: v8:10307
Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66632}
The test started failing (sometimes flaking) on an unrelated CL.
R=gsathya@chromium.org
Bug: v8:10307
Change-Id: If198c2cf518f7a36e54614307462272774d9e48e
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66611}
This CL fixes a special case where a WasmExportedFunction is passed to
the WebAssembly.Function constructor. This is a case that was not yet
implemented in V8, and which is also not specified in the proposal yet.
With this CL we do a signature check of the provided function. If it
matches, the function itself is returned. Otherwise a TypeError is
thrown.
I filed an issue: https://github.com/WebAssembly/js-types/issues/13R=jkummerow@chromium.org
Bug: chromium:1057534
Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66610}
When an empty class is nested inside a class with private instance
methods, like this:
class Outer {
constructor() {}
#method() {}
factory() {
class Inner {
constructor() { }
}
return Inner;
}
run(obj) {
obj.#method();
}
}
The bytecode generator previously generate private brand
initialization for the constructor of Inner by mistake,
because during scope chain serialization/deserialization,
the outer scopes of Inner and factory() are not allocated
or serialized (as they are empty). In the eyes of the bytecode
generator, it then appeared as if Outer is the direct outer
scope of Inner's constructor.
In order to work around this information loss, in this patch
we rely on SharedFunctionInfo instead of the Context/ScopeInfo
chain to maintain the information about private brand initialization.
This is done by shrinking expected_nof_properties to 8 bits and
freeing 8 bits for a second bitfield on the SFI.
Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
Bug: v8:9839, v8:8330, v8:10098
Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66575}
Move the recently introduced extra check for 32-bit platforms so
that it covers all code paths that would be hit by custom/future
memory limit settings.
Bug: chromium:1057094
Change-Id: I5e2217a24578ee82c7bfa753b7d5dcd3d00e1b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083300
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66568}
