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}
Native context independent code generation should, at the moment, not
use any collected feedback.
We implement this by returning InsufficientFeedback from the heap
broker's ReadFeedbackForX methods if currently compiling nci code.
Thus all feedback.IsInsufficient() calls inside the compiler will
return true (disabling feedback-based optimizations).
FeedbackSource::IsValid() (used in generic lowering) can still return
true.
Bug: v8:8888
Change-Id: I198b6457276073e7376c777b206c50726f1b3645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284494
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68726}
Rather than only removing the continuation range for the last return
statement prior to a synthetic return statement, remove the
continuation tracking for whatever statement occurs prior to the
synthetic return.
Bug: v8:10628
Change-Id: Ieb8e393479c9811cf1b9756840bbfdbe7f44a1b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280585
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68719}
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}
After r68405 reduced the default stack size on Arm64 a couple of tests
hit stack limits on the Arm64 android bots. Reduce the argument count
on these tests to avoid this issue.
BUG=chromium:1099623
Change-Id: I8957043b74bd416bb78223599b1a661a4887f54a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280095
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68670}
It seems that the mix of atomic and non-atomic updates to the same
memory location is not working correctly. One fix is changing all memory
updates to be atomic. Another fix is removing the non-atomic access that
happens while the workers are already running (using atomic accesses).
This CL implements the latter.
R=ahaas@chromium.org
Bug: v8:10647, v8:10650
Change-Id: I84b4f3f442b6be3c4ea6e51962a523f443f5e43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273133
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68603}
An 'arguments' array cannot be allocated in young space when its size
exceeds kMaxRegularHeapObjectSize. In this case the optimizations in
JSCreateLowering::ReduceJSCreateArguments are skipped.
Bug: chromium:1098565
Change-Id: I30fdc78a1eb6e51fcd293785a46c9fd78995da9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273121
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68585}
The test was taking more than a minute before CL
https://crrev.com/c/2259933. Afterwards, it takes a lot longer, but I
could never reproduce a hang locally.
Let's re-enable and mark SLOW to increase the chance that it runs to
completion. We can then see how much slower it really got.
Also add some output that helps triaging in case it really hangs.
R=ahaas@chromium.org
Bug: v8:9506
Change-Id: I09a935ca0018517d45c6c008a099b8052bc45c47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273117
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68582}
This is a reland of f7a1932ef9
There was a wpt test in Chrome that expected the incorrect behavior.
I disable the test in https://crrev.com/c/2264418 so that we can land
the fix here.
Original change's description:
> [wasm] Re-exported globals preserve their identity
>
> V8 fails a recently added spec test that when an imported global get
> re-exported, it should preserve its identity. This CL fixes the behavior
> in V8.
>
> Drive-by change: fix the object printer of globals: a global which
> stores a reference type only has a tagged buffer, a global which stores
> a value type only has an untagged buffer.
>
> R=clemensb@chromium.org
>
> Bug: v8:10556
> Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68513}
Bug: v8:10556
Change-Id: I8e1b08fc9f72dde166cba167e6e320e714796769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264097
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68552}
Similar tests are already skipped on tsan, using the same bug to also
skip this test. Note that it's a slightly different test, but based on
the same "worker-ping-test.js".
TBR=ahaas@chromium.org
Bug: v8:9506
Change-Id: Ie8d0aab5b1fd3ae6c77a65fa04ac4772b2836a1c
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267301
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68548}
This reverts commit f7a1932ef9.
Reason for revert: Breaking wasm wpt tests: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/5408
Original change's description:
> [wasm] Re-exported globals preserve their identity
>
> V8 fails a recently added spec test that when an imported global get
> re-exported, it should preserve its identity. This CL fixes the behavior
> in V8.
>
> Drive-by change: fix the object printer of globals: a global which
> stores a reference type only has a tagged buffer, a global which stores
> a value type only has an untagged buffer.
>
> R=clemensb@chromium.org
>
> Bug: v8:10556
> Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68513}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I06eb1996cafe7d4e93a7e59d21679fea239cf961
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264956
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68528}
V8 fails a recently added spec test that when an imported global get
re-exported, it should preserve its identity. This CL fixes the behavior
in V8.
Drive-by change: fix the object printer of globals: a global which
stores a reference type only has a tagged buffer, a global which stores
a value type only has an untagged buffer.
R=clemensb@chromium.org
Bug: v8:10556
Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68513}
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 IsInBounds function is used in a few different places, when used for
bounds checks on 32-bit platforms, size_t for max_memory_size leads to
incorrect out of bounds accesses as size_t is not guaranteed to be
64-bit on all platforms. Use specific uint32_t, uint64_t methods for
Wasm bounds checking instead of size_t.
Bug: chromium:1080902
Change-Id: I0e21f0a310382c8ed0703c8302200d3352495c13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256858
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68500}
Due to recent spec changes, this CL removes the type immediate of
ref.is_null again. Instead we check if the type of the input parameter
is nullable.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: If07d30fe4dd27664be7774422573b2ab2b0dfa20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247654
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68484}
Just a test for now to document how trailing space after async
functions is not removed by SourceRangeAstVisitor.
Bug: v8:10628
Change-Id: I40f0d911c59540ea835c807a2be5b0d1488291d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259852
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68476}
Adjust atomics.wait, atomics.notify semantics for when they are used
with non-shared Wasm memory to mirror the spec change introduced
in: https://github.com/WebAssembly/threads/pull/147. This does not
need to be gated by the flag here, as this will only decode if
the flag is enabled.
Bug: v8:9921
Change-Id: I7f2e018fed6bd131ad4c386def1e838626c28a4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256863
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68468}
This changes black/white list to block/allow list.
Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
Replace by "consistency check", or "validity check", or more specific
wording as appropriate.
R=ecmziegler@chromium.org
Bug: v8:10619
Change-Id: Ifd7852d8f703d5b784d53671b82d65db15722ede
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253855
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68440}
Make sure that the workers do not start running before the main thread
told them so by setting the memory to the first element in the sequence.
Otherwise it can happen that the main thread resets the memory after the
workers already started doing their updates, which results in a hang
(see linked bug).
R=marja@chromium.org
Bug: v8:10625
Change-Id: I959018279e0049900d44457b72146bc37a12bcb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252191
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68429}
When preparsing and detecting a sloppy block function redefinition then
don't mark the variable as assigned to make it consistent with the eager
parser.
Bug: chromium:1053364
Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68415}
This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.
We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.
Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
... for nci code, in which several phases of the compiler are not
active:
LowerJSCreateCatchContext
LowerJSCreateEmptyLiteralObject
LowerJSCreateIterResultObject
LowerJSCreateWithContext
LowerJSGetIterator
LowerJSGetTemplateObject
With this change, the nci variant passes the test suite. Tests
relying on turbofan-specific behavior (e.g. deopts) are skipped.
Bug: v8:8888
Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68381}
Changes:
- Simplify and generalize ToValueTypeString.
- Fix some error messages in msjunit so that they reflect the underlying
error better.
- Change 'exn' -> 'exnref' to match exception-handling proposal.
Bug: v8:7581
Change-Id: I264f6c9aa598a57f39d5a4d01399af64db83a2b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243214
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68364}
We recently changed uc32 to be an unsigned type, and with the invalid
marker being static_cast<uc32>(-1) this DCHECK no longer holds. After
this CL it expicitly checks for the invalid marker.
Bug: v8:10568,chromium:1094226
Change-Id: Idd9efe055b38387e3e37b132cb786cca130767b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245592
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68333}
We want to enable the wasm-bigint implementation by default. However,
at the moment there exist several tests which fail when wasm-bigint
gets enabled. With this CL we adjust or delete these tests so that they
pass once wasm-bigint gets enabled. At the same time we disable these
tests for now, and re-enable them in the CL that flips the flag.
R=jkummerow@chromium.org
Bug: v8:7741
Change-Id: I733bfe7ff19e403913b143e6ea86ab13602ab993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243212
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68328}
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}
