The condition was too strong since we never store Smis into
{previously_materialized_objects}.
Bug: chromium:1094132
Change-Id: I680eb7f175f12d3c44882fd8a9eff0d062eda55f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241517
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68317}
Foozie came up with a mind-boggling example hitting a similarly
mind-boggling bug: object construction (JSObject::New) wants to create
the constructor's function initial map (JSFunction::GetDerivedMap ->
JSFunction::EnsureHasInitialMap). To do so, it calls
JSFunction::CalculateExpectedNofProperties. This harmless sounding
function triggers compilation of the function. Since we're running with
--always-opt, this is an optimizing compilation. Turbofan ends up
depending on the function's "prototype" property, for which it wants to
create the initial map so that it can install the code dependency. That
is, EnsureHasInitialMap is reentered. At this point there is no further
compilation attempt because the bytecode now exists. The initial map is
created and installed on the function, and TF records the code
dependency on that map. When CalculateExpectedNofProperties returns
control to the outer EnsureHasInitialMap, yet another initial map is
created and set on the function, forgetting the previous one and thus
the code dependency.
I'm not sure if this bug can only be observed with --always-opt. The fix
is general.
Bug: chromium:1092011
Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68292}
This caused a CHECK failure after my recent CL.
Bug: chromium:1084820, chromium:1092650
Change-Id: Icdc2a755c6b30ad01dccc908e0e5e137fedf8918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237145
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68263}
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}
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}
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 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}
... 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}
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 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}
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}
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}
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}
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}
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}
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}
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}
We can make better inlining decisions in TurboFan if the CallIC will
provide the feedback that it's seen multiple closures that share the
same SharedFunctionInfo. This is not difficult to do, and it fixes
some frustrating performance cliffs.
Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his
project a year ago.
Bug: v8:2206, v8:10100
Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66512}
Regrettably the previous fix was flawed because a zero increment can
change the type of the induction variable.
Bug: chromium:1051017
Change-Id: I2d7aeffb2065e739445118a2d0c5f7732eecdcbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064222
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66345}
JSCreate can have side effects (by looking up the prototype on an
object), so once we walk past that the analysis result must be marked
as "unreliable".
Bug: chromium:1053604
Change-Id: I36625b14f374e74561c9b539bdf7a02ae767cf7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062396
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66329}
The fix in b8b6075021 was insufficient.
The bug is that induction variable typing does not take into account
that the value can become NaN through addition or subtraction of
Infinities. The previous fix incorrectly assumed that this can only
happen when the initial value of the loop variable is an Infinity.
Bug: chromium:1051017
Change-Id: I8c9ffb2925288b80c00e18e7bc22a556bf540733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051957
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66258}
The verifier tried to assert that the context input of Create*Context
nodes has type OtherInternal (all Context constants have that type).
This didn't quite work because of OSR values so actually it checked
something much weaker. And what it checked still doesn't work because
of dead code, in which the context input might statically be known to
be the undefined value. I'm removing the assertion entirely now.
I suspect that there are other assertions in the verifier that don't
hold in the OSR code or in dead code. We are discussing a more general
solution such as inserting TypeGuards in the relevant cases.
Bug: chromium:1037771
Change-Id: I6fb59c60e7120d5984ea0fe140269f2df6de8708
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010792
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65871}
Add a --max-serializer-nesting flag which defaults to 25.
Fixed: chromium:1034768
Change-Id: Ib68f26ce4bf53db297b25d16a046d275beaec642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969895
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65486}
In this test we expect that the feedback vector is not flushed
so we retain what we have learnt from the earlier executions. If we
flush the earlier feedback the code might deoptimize again and the test
fails. Hence adding --no-stress-flush-bytecode and --no-flush-bytecode
flags.
Bug: v8:10035
Change-Id: Ia71748e83d64a731f595fed7f5b85a8dafa2b31a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65472}
MapRef::GetStrongValue now returns an Optional to account for the case
where we can't figure out the name of the bound function during
serialization. We could reach out to the heap in the future in this
case.
Fixed: chromium:1034203
Change-Id: I9fa81921b5dbd8bc9f68aa3c10921bc01b695a6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967386
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65470}
Also make return and unconditional jumps kill the environment instead
of clearing it. This was still leftover from before we introduced
liveness and prevented sharing as well.
Bug: v8:7790
Change-Id: Ic79d64c9eaedf608d26e3265d4b27d21f7f3dfe1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948710
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65345}
Add serialization of the virtual closures for Function.ptototype.apply
and Function.prototype.call. Also add tests for those.
Bug: v8:7790
Change-Id: I26374009c09958943ef36eae283a270875234e40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943155
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65298}
The flag combination --gc-interval=500 --stress-compaction
--stress-flush-bytecode, combined with baking mjsunit.js into the
custom snapshot, caused type feedback for "deepEquals" to be
forgotten, leading to an unexpected soft deopt. Forcing type feedback
collection with %PrepareFunctionForOptimization() fixes that.
Change-Id: I954c7ecbe70ca5b803a5fa7cd809c118f7659f21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946347
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65281}
If the inputs are Unsigned32OrMinusZeroOrNaN and we want to compile for
an Unsigned32 result, we still need to deopt if the RHS is zero (because
that must produce NaN).
Bug: chromium:1028862
Change-Id: Ib5b7cd10f8c4ec9a76b75a2b408729f1ca86ea3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943150
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65260}
A call to this intrinsic will produce true in the interpreter and false
in optimized code. This is useful for writing tests.
Change-Id: I64d06ed062027e723eca82d6f879202244f21fdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939750
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65240}
The serializer was missing the opportunity to process calls later
constructed by JSNativeContextSpecialization::InlinePropertySetterCall
and InlinePropertyGetterCall. Added a test to ensure we're not missing
the data anymore.
This drops the "Missing data" warnings when running ARES-6 from 1044
to only 12.
Bug: v8:7790
Change-Id: Ic4b8a4cb2ac3927371b75f22de011b9957502319
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1937147
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65220}
This flag has had no effect since mid 2017 when its use-site was
accidentally removed (in https://codereview.chromium.org/2902533003).
Change-Id: I81436b064c2664deff781ad6d75ad47937e3fdc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934333
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65172}
This brings the number of optimization misses (with concurrent
inlining) in Octane's typescript from 179 down to 3 (the actual
score doesn't seem to change but it's already on par with the
default configuration).
Bug: v8:7790
Change-Id: Ia4ade2eafc035491d3eac9081383c72b435e8df6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924441
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65152}
Subsequently LookupHolderOfExpectedType should be called only
when we have installed handler code.
Bug: chromium:1024936, v8:7790
Change-Id: I33a0a7232afaba8455a0cec1fdc56251947419d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930905
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65148}
Allow sharing of hints and modification of shared hints such that
feedback can be propagated to the hints for the corresponding
register, AND all alias registers. Even propagation from an inlined
callee back to the caller is possible.
Bug: v8:7790
Change-Id: I96b3c5e41613efa5711ab758db1c3ef7f7ae6418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914560
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65139}
This CL implements torque builtins for BigInt subtraction and extends
the compilation pipeline to lower calls to the generic subtraction
to SpeculativeBigIntSubtract and later to BigIntSubtract with
necessary checks in case of BigInt feedback.
The CL also implements lowering of these operators to native machine
word operations on 64 bit architectures if they are used in a
truncating context (aka BigInt.asUintN).
Bug: v8:9407
Change-Id: Idf5da14c380bc7c12375e7f084a3e1c455303f5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895566
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65037}
Bytecode flushing bit me again.
Bug: v8:9945, v8:9983
Change-Id: I9e4f9dd5e1793d60b24def447a8374e550fa248a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924352
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65036}
... by disallowing checkpoint elimination across function boundaries.
See the comment in checkpoint-elimination.cc and the tests for details.
Bug: v8:9945
Change-Id: Ibf4ab6f0e4e709e26d3c4428a082ef45dcbeb8b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1906208
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65027}
The serialization of Construct was accidentally using the wrong hints
for the receiver. Also, the recursion in ProcessCallOrConstruct was
not quite right: for example, it overwrote the accumulator hints in
each recursion.
With this CL the Octane raytrace score for --concurrent-inlining is
back to the default configuration's score.
Bug: v8:7790
Change-Id: I501c9cc0b0c8de04520742b9c6b392a4a732bf78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921789
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65011}
... even with ptr-compr.
Although full uintptr-sized TypedArrays are not supported yet
we may already start using uint32-sized typed arrays as we no
longer rely on TypedArray length to be a Smi.
Bug: v8:4153
Change-Id: If179541ad4f02c4ec7de9d1f3836138fe526d8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1905847
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64897}
When the serializer encounters a JSConstruct, it now serializes the
initial map of the new_target to enable further opitmizations in
JSNativeContextSpecialization.
Add regression tests as well.
Bug: v8:7790
Change-Id: Ifab2b58c64a341744e833ed063e9695d74a5cdce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900457
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64886}
Changing the target of JSCall nodes (e.g. while lowering higher order calls)
now preserves feedback and speculation mode to allow further (speculative)
optimizations. A flag is introduced to mark feedback unrelated to the call
target after such a transformation. This flag is used to prevent access to
the feedback without the need to invalidate it.
Bug: v8:9702
Change-Id: I311d3a4b1b22d6f65e5837a23b0b7585c8d75eed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844788
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64733}
