Object materialization did not correctly deal with a mismatch between
current representation of a field value and expected representation.
This is an attempt to repair the situation.
Bug: chromium:1084820
Change-Id: Ib337cbaf5e36a5a616b6a6cb0ddf51018d49b96a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228330
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@{#68231}
Due to recent spec changes, We do not have to check if ref.func
instructions in global declarations only refer to declared functions.
Additionally functions referenced in exports and globals are now
considered declared.
R=ecmziegler@chromium.org
Bug: v8:10556
Change-Id: I79856c7d68155a04eb36769ceed8a58fe62a9f9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228653
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68190}
Speculative BigInt addition fails to throw the expected exception
when called with non-BigInt inputs when the result of the computation
is unused. In paricular, this CL does:
- Remove kNoThrow on speculative BigInt operators
- Fix AddWithFeedback to not lose type feedback if builtin throws
to elide existing deopt loops
- Add handling of TypeCheckKind in RepresentationChanger where this
was previously ignored
Bug: chromium:1073440
Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68181}
We use StoreOwnIC to initialize the object after creating a new object
with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64
to indicate an uninitialized double field. When we actually try
to store a NaN value into that field later using StoreOwnIC, IC avoids
actually storing the new value since the existing value is "same as"
the value we try to write. The float comparison treats all NaNs as
equal. In this particular case, we should actually store the new value
since kHoleNaNInt64 value is used to represent an uninitialized field.
This cl just stores the new value even when the existing value is same
as the new value for double fields. The check is still required to
correctly track const fields.
Bug: chromium:1082293
Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68167}
All subtyping has been removed from the reference-types proposal. This
CL implements this proposal change now in V8.
R=manoskouk@chromium.org
Bug: v8:10556
Change-Id: I08ef064952278e03ea655461fa9f0c96426157c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222345
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68152}
Even in unreachable code, the targets of br_table have to have matching
types.
R=thibaudm@chromium.org
Bug: v8:10556
Change-Id: I2e85df3cb92f7910a6bcb5ac03927c424194660d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218062
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68148}
With recent changes to the anyref proposal, null refs now have a type
immediate which declares the type of a null ref constant. Likewise,
the RefIsNull instruction is type aware now. This CL addresses these
proposal changes now.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I810dfa3a4ab4389afc9639f897cee5d43e9b62cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215172
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68141}
This reverts commit 76debfda32.
Reason for revert: Nullptr access in new test: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/37265
Original change's description:
> [wasm-simd][liftoff] Fix I64x2Mul
>
> 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}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I5fd337b71d82d262d36ff410077a11c17b50036b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1088273
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226756
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68117}
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}
