ReduceJSToNumeric() can fail to update the node type after changing
it's operator to JSToNumeric.
BUG=chromium:1158049
Change-Id: Iaabb3676f8ad9563903b81de2e7eecdcc92cbc0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593336
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71771}
Adds support for generating code to migrate instances if a map
is a migration target, to dynamic check maps.
BUG=v8:10582
Change-Id: Id26d95491869fc68a5633398d230237eb88648d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575058
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71658}
In order to reduce the codegen size of dynamic map checks, add the
ability to have an eager with resume deopt point, which can call
a given builitin to perform a more detailed check than can be done
in codegen, and then either deoptimizes itself (as if the calling
code had performed an eager deopt) or resumes execution in the
calling code after the check.
In addition, support for adding extra arguments to a
deoptimization continuation is added to enable us to pass the
necessary arguments to the DynamicMapChecks builtin.
Finally, a trampoline is added to the DynamicMapChecks which saves
the registers that might be clobbered by that builtin, to avoid
having to save them in the generated code. This trampoline also
performs the deoptimization based on the result of the
DynamicMapChecks builtin.
In order to ensure both the trampoline and DynamicMapChecks
builtin have the same call interface, and to limit the number
of registers that need saving in the trampoline, the
DynamicMapChecks builtin is moved to be a CSA builtin with a
custom CallInterfaceDescriptor, that calls an exported Torque
macro that implements the actual functionality.
All told, this changes the codegen for a monomorphic dynamic
map check from:
movl rbx,<expected_map>
cmpl [<object>-0x1],rbx
jnz <deferred_call>
resume_point:
...
deferred_call:
<spill registers>
movl rax,<slot>
movq rbx,<object>
movq rcx,<handler>
movq r10,<DynamicMapChecks>
call r10
cmpq rax,0x0
jz <restore_regs>
cmpq rax,0x1
jz <deopt_point_1>
cmpq rax,0x2
jz <deopt_point_2>
int3l
restore_regs:
<restore_regs>
jmp <resume_point>
...
deopt_point_1:
call Deoptimization_Eager
deopt_point_2:
call Deoptimization_Bailout
To: movl rax,<slot>
movl rcx,<expected_map>
movq rdx,<handler>
cmpl [<object>-0x1],rcx
jnz <deopt_point>
resume_point:
...
deopt_point:
call DynamicMapChecksTrampoline
jmp <resume_point>
BUG=v8:10582
Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71545}
SL's VisitSpeculativeIntegerAdditiveOp was setting Signed32 as
restriction type even when relying on a Word32 truncation in order to
skip the overflow check. This is not sound.
Bug: chromium:1150649
Change-Id: I3113a2102c62d6ecef342c98d25daf31431c01ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557498
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@{#71364}
When accessing a super property which is a getter, the receiver
is not restricted the same way as when doing normal property access.
In particular, the receiver can be null / undefined.
Bug: v8:9237, chromium:1148758, v8:11161
Change-Id: Ic6bc2053e5d046d4b19e868312aa9b50025256a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2549941
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71281}
... to --turbo-dynamic-map-checks. With the upcoming use in NCI code,
this feature is no longer used exclusively by Turboprop.
Bug: v8:8888
Change-Id: I61e01db086fd2e8566d2e2a09574be74b6e5a7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546693
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71263}
Split globals.js into two parts, one being skipped on NCI due to
assertions about optimization status.
Change-Id: Ifc572526d9c6aed369802a65d12c4456cde65ce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2539909
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71199}
Don't deopt when a PropertyCell changes from readonly to writable.
Turbofan doesn't depend on readonly-ness unless the property is
also non-configurable, in which case such a change can't happen.
Change-Id: I3d1078a8adf1ec1b16d973dd71c4295d71003a8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2531791
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71184}
which was enabled a long ago and is not supposed to be disabled.
In addition this CL adds Representation::MightCauseMapDeprecation()
predicate and ensures it's consistent with the existing
MostGenericInPlaceChange() and CanBeInPlaceChangedTo().
Bug: v8:11104, v8:8865
Change-Id: Ia8046b76822c9b20fe3ce85de6b98570334aad21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2527088
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71151}
In a few places we incorrectly assumed to know the instance type of the
heap object. In particular, in JSCallReducer::ReduceDataViewAccess,
doing map inference on the receiver and determining that all maps are
JSDataView maps does not guarantee that the receiver is a JSDataView
constant because we might deopt before getting to the data view
operation.
Bug: chromium:1146652
Change-Id: I1611308c3ebe0d33fa6b0cf0938d777b4e6449ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2524440
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71034}
Due to the previous change to that function, we can end up with
set (non-null) fields even when the overall serialized_ field is
unset. This can cause DCHECK failures (I don't think it's otherwise
observable).
Bug: chromium:1142240,v8:7790
Change-Id: I2711fae8a73438277caf7aa539f24d628b03153c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2497170
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70753}
The dynamic map check builtin loads the feedback vector from the
function's frame, therefore it doesn't work if we inline the
function. We don't do inlining on TurboProp so this is fine, but
it was possible to enable dynamic map checks on TurboFan which does.
This change prevents that, and also makes the dynamic map checks flag
specific to TurboProp and no longer an implication, which also allos
it to be switched on the command line independenly of --turboprop.
BUG=chromium:1141502,v8:9684
Change-Id: I365de461a6373335a45a7a154af7d4cf1c13dc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2494928
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70737}
The TryMigrateInstance should be passed the instance object to migrate,
not the map of the object. Also make the runtime function explicitly
check for JSObjects.
BUG=v8:9684
Change-Id: I03605d9f3103b618243c12ad0b63035484ef4134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487270
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70731}
Gracefully handle hugely nested JSBoundFunctions by checking against
the local isolate's stack limit in relevant recursive functions.
This is based on d734bb4c5d (which was
reverted).
In order to get access to the local isolate, the CL replaces the heap
broker's LocalHeap pointer with a LocalIsolate pointer.
Bug: chromium:1125145
Change-Id: I15d6265c7dfcd8a70af4ab4ce6f30149a886be00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480682
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70654}
Instead of loading the map from the feedback vector for monomorphic
access, this CL directly inlines the expected map constant as a static
check.
In case this static check fails, we call out to a builtin which performs
additional dynamic map checks.
There are several dynamic map checks performed by the builtin for various
cases such as:
(a) IC is monomorphic with a map that's different from the initial
static map that we checked, in which case we perform another dynamic
map check.
(b) IC is monomorphic but incoming map is a deprecated map in which case
we call out the runtime to migrate this incoming object to a new map and
then try to handle it.
(c) IC has now transitioned to polymorphic in which we use the old
dynamic polymorphic checks to validate the map and handler.
Bug: v8:10582, v8:9684
Change-Id: Id87265ed513e4aef87b8e66c826afbf10f50a1d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429034
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70304}
Using associative property of addition: (x + A) + B => x + (A + B).
Note: A and B need to have the same sign and we need to check that
(x + A) isn't used anywhere else.
20% perf improvement of the following function.
function f(n) {
var c = 0;
for (var i = 0; i < n; i++) {
c = c + 2 + 3;
}
return c;
}
for n = 10_000_000.
Before: 7.31s.
After: 6.05s.
Bug: v8:10305
Change-Id: If45d1cad6128a9a25cb9f43a4828ae28d594a84b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2365221
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70064}
JSInliningHeuristic::Finalize did not take into account that by the
time it gets called some of the candidate nodes may have changed to
non-call operators.
Bug: chromium:1127319
Change-Id: I180ed36de98455be6b55790ba7bdb4391ff5fd5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2409273
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69874}
- serializer-*:
In some stress configuration, the new map of x was GC'd at the beginning
of optimization, thus generating a soft-deopt for the store to x (thus
in turn skipping inlining of f).
- native-context-*:
In some stress configuration, f had its feedback flushed.
Bug: v8:10892
Change-Id: Icd9f9c0ba6feb938ae8c3b0031b02b766f2e3f91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404764
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69837}
My last CL introduced a null-pointer bug there.
Bug: chromium:1126771, v8:7790
Change-Id: Ib16317dea14c9fbad7951cb28ce7bb8bb9ce41c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2402037
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69799}
The test relies on certain maps not dying but didn't ensure that.
Bug: v8:10783
Change-Id: I708f7fc027ee0bf5656be9bb4f29130f5b924597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340912
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69282}
If incoming map is deprecated, generate code to migrate the map. Since
this involves generating additional code and a call to runtime, we only
do this if one of the receiver maps was a migration target when
optimizing this function. If not, we deoptimize and discard the
optimized code if we see a deprecated map. This is to avoid bailout
loops when we see deprecated maps.
This change does the following:
// We generated code to migrate deprecated maps only if one of the maps
// in feedback vector is a migration target.
if ( there are migration targets in feedback)
{
if (checkMaps fails) {
if (incoming map is deprecated) {
migrate the map
checkMaps with the new map
} else {
bailout
}
}
} else {
if (checkMaps fails)
bailout;
}
Bug: v8:10582, v8:9684
Change-Id: I8a04c77ed209dd2fb0300a783d844f2335a678c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292231
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69179}
The bug was that the allocation of the result array (before the loop)
was using the outer frame state, thus returning the allocation's result
(an array full of holes) as the return value of the map operation in
case the allocation triggers a lazy deopt.
Bug: chromium:1104514
Change-Id: I9a6db8a5860472e1b438b6b54414938d61e166c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324249
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69129}
This cl also
1. Fixes a bug in effect-control-linearizer where we should have
converted fixed array length from Smi to integer
2. Also prints deopt location for the new "bailout" deopt type on
--trace-deopt.
Bug: v8:10582, v8:9684
Change-Id: Iafc5e8abbca5252a8783a5a1184a1667a7f708a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297460
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69115}
Due to an optimization in how resumable functions are compiled, we can
actually see another Oddball type as StrictEquality inputs. I'm giving
up on getting the DCHECK right and removing it entirely.
Bug: chromium:1102683
Change-Id: Ia210777c66641e898e96900713710a51ebed311d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287494
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68735}
ForInNext can get lowered to a low-level call to the ForInFilter
builtin. We currently type low-level Call nodes simply as Any, leading
to a CHECK failure when the verifier expects a primitive.
This CL fixes the issue simply by manually setting the type as part of
the lowering. An alternative would be to have the Call typing inspect
its input similar to what the JSCall typing does. We can consider this
if we hit the same issue in other cases.
Bug: chromium:1102053
Change-Id: I6682d8cf95c6a3ebaff9c8de677aa20ca676573f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282523
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68688}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
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}
