The test have been rewritten to be more robust -> maybe they're
robust enough for the GC fuzzer (DelayedTasksPlatform)?
Bug: v8:10239
Change-Id: I743cc2f804357aaef888bff7985dfb68a7feec5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342848
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69287}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
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}
We have the implicit assumption that Liftoff code will never be
serialized, and we start relying on that when implementing new features
(debugging, dynamic tiering).
This CL makes the serializer fail if the module contains any Liftoff
code. Existing tests are changed to ensure that we fully tiered up
before serializing a module (similar to the logic in Chromium).
The "wasm-clone-module" test needs to serialize the module before
enabling the debugger.
Note that chrome currently only serializes a module after it fully
tiered up, so that should be fine. If other embedders need the ability
to serialize a module in an arbitrary state, we will have to fix this
later. With this CL we will be on the safe side though and (gracefully)
fail serialization instead of accidentally serializing Liftoff code.
R=ahaas@chromium.org
Bug: v8:10777
Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69276}
This is a reland of 28ead05405
The failure is a test that is sensitive to adding a function
in a FunctionTemplate in d8: https://bugs.chromium.org/p/v8/issues/detail?id=10783
Original change's description:
> [Atomics.waitAsync] Fix removing multiple nodes when Isolate deinits
>
> RemoveNode already nullifies the next_ pointer of FutexWaitListNode,
> and DeleteAsyncNode was trying to retrieve it.
>
> Bug: v8:10239
> Change-Id: I595885de87f433d263eeacfc825a689efd467f5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332812
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69259}
Bug: v8:10239
Tbr: leszeks@chromium.org
Change-Id: Icec590354886433a0b41c8f9b7af7101b54b7690
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339469
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69275}
We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.
With this CL the V8 implementation becomes spec compliant in this
regard.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
Just like the optimized code cache, the compiler should check the
isolate cache for NCI code objects and return them if they exist.
Drive-by: Skip additional tests to fix the nci_as_highest_tier test
variant. These are related to interactions with deoptimization, which
NCI code doesn't fully support yet.
Bug: v8:8888
Change-Id: I6253811f96993796cfc38fff0da7ffb4f1a5eb24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339095
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69251}
This test uses a i64x2.shr_s to shift a v128 with all bits set by 1,
resulting in v128 with all bits set (no change). This value is then
dropped, and param[2] (3), is returned.
Without the fix, -1 is returned, since i64x2.shr_s overwrites the
register for param[2] with 0xffffffff.
Bug: v8:10752
Bug: chromium:1111522
Change-Id: I0310bf6039be780a6738689069cdbcfa3a24bbdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335779
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69233}
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}
If we are near the stack limit, calling the proxy method might not work
any more. Instead of crashing because of an empty MaybeLocal, handle
this gracefully.
Drive-by: Minor refactoring in TryGetValue.
R=tebbi@chromium.org
Bug: chromium:1110001
Change-Id: I07e7773768166b3dbea2e6b75a3ab8b24bfeee53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332156
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69161}
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}
This generic wrapper builtin is currently used only when the wasm
function has no parameters and no return value.
Added a new V8 flag to use this generic wrapper.
Also added a JS test function for this generic wrapper.
Bug: v8:10701
Change-Id: Id8cd1771f26922927363b715d8a6ffd384a143ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2307240
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69097}
This test should've been rewritten in the last
batch rewrite but wasn't.
Bug: v8:10239
Change-Id: Ic2949e6282f72975898ab7e9aefe3210bba71fbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2319988
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69072}
Using uint8_t[] causes decay to pointer issue, which manifests in
copying garbage values in the call to WriteLittleEndianValue. Change it
to use a std::array, which doesn't have the decaying behavior.
Also add a regression test from comment#6 of the linked bug.
Bug: v8:10731
Change-Id: I4a1ca69fe99806642e9931625ca7aeab6663f955
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316465
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69052}
This reverts commit d8f8a7e210.
Reason for revert: Breaks code_serializer variant - https://cr-buildbucket.appspot.com/build/8874070652992164976
Original change's description:
> Reland "[flags] warn about contradictory flags"
>
> This is a reland of b8f9166664
> Difference to previous CL: Additional functionality to specify
> incompatible flags based on GN variables and extra-flags, used
> to fix the issues that came up on the waterfall.
>
> This also changes the rules regarding repeated flags: While
> explicitly repeated flags are allowed for boolean values as long
> as they are identical, repeated flags or explicit flags in the
> presence of an active implication are disallowed for non-boolean
> flags. The latter simplifies specifying conflict rules in
> variants.py. Otherwise a rule like
>
> INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
> "--gc-interval=*": ["--gc-interval=*"],
> }
>
> wouldn't work because specifying the same GC interval twice
> wouldn't actually count as a conflict. This was an issue with
> test/mjsunit/wasm/gc-buffer.js, which specifies
> --gc-interval=500 exactly like the extra flag by the stress bot.
>
> Also, this now expands contradictory flags checking to d8 flags
> for consistency.
>
> Original change's description:
> > [flags] warn about contradictory flags
> >
> > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
> >
> > Bug: v8:10577
> > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> > Reviewed-by: Clemens Backes <clemensb@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#68168}
>
> Bug: v8:10577
> Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68989}
TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org
Change-Id: I7969065b0edbc463a94e530485bc2ab623d77b62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312782
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68992}
This is a reland of b8f9166664
Difference to previous CL: Additional functionality to specify
incompatible flags based on GN variables and extra-flags, used
to fix the issues that came up on the waterfall.
This also changes the rules regarding repeated flags: While
explicitly repeated flags are allowed for boolean values as long
as they are identical, repeated flags or explicit flags in the
presence of an active implication are disallowed for non-boolean
flags. The latter simplifies specifying conflict rules in
variants.py. Otherwise a rule like
INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = {
"--gc-interval=*": ["--gc-interval=*"],
}
wouldn't work because specifying the same GC interval twice
wouldn't actually count as a conflict. This was an issue with
test/mjsunit/wasm/gc-buffer.js, which specifies
--gc-interval=500 exactly like the extra flag by the stress bot.
Also, this now expands contradictory flags checking to d8 flags
for consistency.
Original change's description:
> [flags] warn about contradictory flags
>
> Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/
>
> Bug: v8:10577
> Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68168}
Bug: v8:10577
Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68989}
On desktop systems, we use a very basic tiering strategy: Everything is
initially compiled with Liftoff, and once that is done, the module can
start being used. Concurrently to the execution, we re-compile all code
with TurboFan, and hot-swap each function once TurboFan finishes.
We should start using a more dynamic strategy where each function is
tiered-up when judged necessary. This change will then tier-up each
liftoff function once it has been called 5 times.
I then added a counter in the native module, that is updated directly
from Liftoff code, and a runtime call is then made when the counter
reaches the goal.
R=clemensb@chromium.org
CC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I8dc2b02fdff8d97781bb1cf496886594b3d7f644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306803
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68971}
With work on NCI proceeding, it makes sense to test multiple
pipeline configurations.
The nci variant (passes --turbo-nci) now spawns dedicated NCI
compilation jobs and inserts generated code into the code cache.
The nci_as_highest_tier variant (passes --turbo-nci-as-highest-tier)
simply replaces TF with NCI code (no extra jobs, no extra caching).
This mode stresses NCI generated code more than the nci variant, in
which NCI code only runs on cache hits.
Bug: v8:8888
Change-Id: I4c2a43cce5271a6c288e7aba195dcc9daed6af9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299361
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68964}
The CanTailCall check only passes if the return locations are the
same in the caller and the callee. However, stack returns are expected
to be at a different offset depending on the stack space reserved for
parameters.
R=clemensb@chromium.org
Bug: v8:7431
Change-Id: Iaac15fce889d6cd7d1ac88f320a872202281fb5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289789
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68933}
The {operator==} on {VarState} did not check the spill offset, so when
merging stack states, we forgot to move stack values if both source and
destination were stack slots, but at different offsets.
This CL fixes this by removing the {operator==}, because the semantics
(and use) are not clear, and it's only used in one place anyway.
The equality check was mostly redundant, so inlining it also makes the
code smaller and faster.
R=ahaas@chromium.org
Bug: v8:10702
Change-Id: I6c8b2cfd1002274175c9a17d305692e4631fd7dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304574
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68916}
We cannot allocate large arrays exceeding the size of
kMaxRegularHeapObjectSize in young space. Bailout of optimization in
such cases.
Bug: chromium:1105746
Change-Id: I4f7357c2dd7b3e70d747f9067660725ecf6ae768
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300481
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68889}
The snapshot code assumes that the entire snapshot's length fits into
an int, which implies that it doesn't support individual objects that
are bigger than that. That's okay, because it isn't reachable from
user code, and embedders would notice at compile time when they run
into this limit. So we can just continue to skip the few regression
tests we have for huge TypedArrays in the stress_snapshot variant.
Change-Id: Ib37c0582763d549a3d5c5ccc3a78d200b176f3b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299373
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68874}
mjsunit/regress/regress-896326.js failed on mips simulator, because mips
simulator has larger stack size and won't throw the expected RangeError
exception.
This CL set sim-stack-size to 100K in regress-896326 just like setting
the native machine's stack-size.
Change-Id: I51328b10a7b54addab2adb90401680c0581d7ee2
Bug: v8:10709
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299880
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68865}
This is a follow-up fix for
https://chromium-review.googlesource.com/c/v8/v8/+/2292230
In this CL fixes the case when the property cell is added to the
dictionary but the value is not actually stored which leaves
PropertyCell with the hole in the dictionary.
Now the logic for GlobalDictionary matches the logic for
NameDictionary - the property cell is added to the dictionary in
LookupIterator::ApplyTransitionToDataProperty().
Bug: chromium:1104711, chromium:1105383
Change-Id: I56da16d85d13288fbc41fd60dbce556fec5e7d18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297472
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68860}
The named LoadIC code was missing a check for "names" that
convert to TypedArray indices. This was flushed out by the
recent bump of the max TypedArray size from 2^32-1 to 2^32.
Named StoreICs had the same bug; fixed here as well.
Bug: v8:4153
Fixed: chromium:1104608
Change-Id: I6bd2552d6ccc238104f92e7b95d19970d4a75dae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295606
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68840}
For 64-bit binary operations, Liftoff on arm made the assumption that
register pairs are always ordered, i.e. the register code for the low
word is lower than the register code for the high word.
Ensuring this was only implemented in {GetUnusedRegister} in
https://crrev.com/c/2168875. Other cases were missing though, e.g.
return values, but also different places were we
construct register pairs internally.
Thus, this CL removes this constraint again and instead handles
unordered register pairs in 64-bit binary operations on arm.
R=thibaudm@chromium.org
Bug: chromium:1101304
Change-Id: I4cd9fb1577f82ab06d34c9dde6533cf04a2cade7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287870
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68752}
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}
