This reverts commit b12ba06edf.
Reason for revert:
After further discussion we decided to stick with fdlibm.
Original change's description:
> [builtins] stop using imprecise fdlibm pow
>
> This CL reinstates the old pow implementation which calls out to the
> system implementation of pow.
>
> Bug: v8:9622
> Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66303}
TBR=yangguo@chromium.org,neis@chromium.org,hpayer@chromium.org,me@gus.host
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9622
Change-Id: I941f70c7432cd2fab86e0eadcb2e1a9ec8195e91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072746
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66452}
Move load splat and load extend ops into the list of SIMD memory
opcodes, since they similarly take an i32 and an memarg. This fixes the
OpcodeLength calculation in function-body-decoder-impl.h.
And in turn, fixes the mjsunit test code that the fuzzer generates. See
the regress-1055692.js file for the weird S8x16LoadSplat followed by 2
kExprUnreachable, where the kExprUnreachable really is a memarg
{0x0, 0x0}. This bug was caught by the fuzzer, and that was the
generated test (with small fixes to add kExprDrop), so leaving it as it
is.
Bug: chromium:1055692
Change-Id: I743b6beb82350b5fea22c8dd10b546a02741cfed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071401
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66439}
This is a reland of 03d5a7ba9b
Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
This is a reland of 548fda4afb
regress-1054466 is modified to not use 64x2 operations, since that was
causing problems on noavx/nosse builds, which requires scalar lowering,
and scalar lowering for 64x2 ops is not implemented.
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
Bug: chromium:1054466
Change-Id: If88f1ff2fb17aaa3727758cda5b368be1c6d9bd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071396
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66423}
This reverts commit 548fda4afb.
Reason for revert: Segfault on nosse bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/35905?
Original change's description:
> [liftoff] Check fp_pair when looking up register for reuse
>
> Given two registers that are both not gp_pair, one could be an fp_pair,
> and the other not, and we will incorrect call == on them. The current
> check needs to be expanded to check that both registers are fp_pair.
>
> Bug: chromium:1054466
> Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66402}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I56f13406ef3cc3793c9d0e2273c4dc5fb0e3de38
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1054466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069327
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66405}
Given two registers that are both not gp_pair, one could be an fp_pair,
and the other not, and we will incorrect call == on them. The current
check needs to be expanded to check that both registers are fp_pair.
Bug: chromium:1054466
Change-Id: Ib986c002a8a5cadb9668458597a797cecfd971b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070006
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66402}
Make sure the "initial pages" memory limit is enforced correctly and
throws a CompileError when exceeded.
Bump the "maximum pages" memory limit to 65536.
The --wasm-max-mem-pages flag now controls the "initial pages" limit;
the "maximum pages" limit is always 65536 as spec'ed.
This CL depends on https://github.com/WebAssembly/spec/pull/1121.
Bug: v8:7881, v8:8633
Change-Id: I68d07cef56633b8b8ce3b3d047c14e1096daf547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2035876
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66400}
An enum cache can only be referenced together with the map that owns the
entries that are needed. Otherwise the entires can be trimmed away if
the map dies because of transitions.
Bug: chromium:1050046
Change-Id: I5bc9dd65ca092c3d5ebc08ce553f6f1dc980d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066959
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66375}
This reverts commit 03d5a7ba9b.
Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243
Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.
In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
This CL reinstates the old pow implementation which calls out to the
system implementation of pow.
Bug: v8:9622
Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66303}
The previous code was relying on {compilation_unit_builder_} to check if
a section was after or before the code section. This only works for the
first section after code section, since the compilation unit builder is
then reset. Use an additional field to track this instead.
R=clemensb@chromium.org
Bug: chromium:1051912
Change-Id: Id1dfa803ecde2cf77f206ea781c007fc61168942
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054099
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66265}
These tests rely on predictable opt & deopt timings. Also add the
--opt flag to tests to force optimization even in configurations that
contain the --no-opt flag.
Bug: v8:9972,chromium:1049982
Change-Id: Ic161d188ebfae9aaae6a160d365413abedfee5f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050402
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66231}
This fixes a bug in lazy deopts caused by calls to the callback function
in Array.prototype.reduce and reduceRight.
The deopt continuation expects the *next* iteration's index value but
we actually passed the current iteration's value.
The user-visible effect of this bug was that sometimes, an unexpected
additional call to the callback function would occur.
It was introduced by https://crrev.com/c/1934329.
Bug: v8:9972,chromium:1049982
Change-Id: Icfd2ef076209e20602f54d4662220e1d4c5d07ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049850
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66226}
If we need a byte register, but {src} is none, we should definitely use
another register.
R=ahaas@chromium.org
Bug: chromium:1048241
Fixed: chromium:1048241
Change-Id: I3396826986e1823250ad6855b84f4b05faaf3b90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036073
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66095}
Factory::NewFunction now requires names passed into it to be flat.
Make sure to flatten Wasm function names when creating new Wasm JS
functions.
Fixes: chromium:1047368
Change-Id: I7bd2d8bc83ae8fab901ab469872bce0f703fc3ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030738
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66064}
As discussed offline, the current implementation implement each
situation separately. I think we can simplify the code a lot by sharing
code between the different paths.
This CL does that by
1) implementing the kI64Store case separately, because it does not have
all the register contraints that the others have, and
2) moving all logic to ensure that the {src} register is usable before
the switch, such that it's shared by all the compare-exchange cases.
As a side produce, this also fixes issue 1045225, because for i64 stores
which actually only use the lower half of {src}, only that half will be
pinned.
R=ahaas@chromium.org
Bug: chromium:1045225, v8:10108
Change-Id: I0be025b9706d563835ae6337d45b88e0233eacad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029414
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66062}
There was a bug in the function body decoder where
type checking of brtable only happened if the brtable
instruction is reachable. However, type checking is
required in all cases where brtable "not unreachable".
The difference between reachable and "not unreachable"
is a state called spec-reachable where a clever
compiler can already infer that the code will be
unreachable (e.g. a memory access is out of bounds
just by the offset and therefore unconditionally
traps), but the spec can not. If an instruction is
only spec-reachable, it still has to be type checked.
R=clemensb@chromium.org
FIX=chromium:1046472
Change-Id: I7e9f1108597871615c0d443a0e94de35a0207b5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2027990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66049}
Copying one object's named properties is always fine, even if one of
the names could be a large index on a TypedArray. Mark the LookupIterator
as OWN_SKIP_INTERCEPTOR to avoid the DCHECK.
Bug: chromium:1044909
Change-Id: I6918186a4b50df7865de3572cb674fd7d6eadb78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023558
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66027}
... which didn't check writability of array length on appending
a new element to an array.
Bug: chromium:1041251
Change-Id: I6935e505a4844e5b22abe9d4a42786619499daa6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023551
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66023}
The compiler assumes (for loads) that the property cell of a
non-configurable global property never gets invalidated.
Bug: chromium:1044919
Change-Id: I27f6ce30fb9a21e2c1e5310f25e9bb973ebbc266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023562
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66021}
Converting an object to an array length can freeze the array whose
length is being set, but SetLength for the frozen elements accessor
is supposedly unreachable. This fix extends the existing special
handling for suddenly-readonly lengths to cover this case as well.
Prior art: https://codereview.chromium.org/2543553002
Bug: chromium:1044911
Change-Id: I85d2e79446a8d9c1d22cd86ddf828328bf51a1a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023555
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66020}
The actual allocatable size still depends on the allocator;
in particular Blink's ArrayBufferAllocator is currently limited
to 2GB.
WebAssembly memories are not affected by this change (i.e. still
capped at 2GB as well).
For 32-bit platforms, the limit remains at 2**30-1 (=max smi) elements.
Bug: v8:4153
Change-Id: If0d6047dd4061028688d85a3dc0a2684dcca8693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007495
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65924}
The interpreted-frames-native-stack flag has been broken since pointer
compression was enabled. This fixes the load of the field.
Bug: v8:10138
Change-Id: I746407a7a5680c5d3e9a3b190371af00818282b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011206
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65878}
This adjusts parsing of negative numbers in UnaryExpression and
MultiplicativeExpression to return double if the token is -0.
R=clemensb@chromium.org
TEST=mjsunit/regress/regress-6838-4
BUG=v8:6838
Change-Id: I6c2113b520c3831f4a5101f0a963f49c1eb9d7d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007272
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65862}
The advance-by parameter can contain negative numbers, but until this
CL was treated as unsigned.
Bug: v8:10072,v8:9330
Change-Id: Ib9a9c2d47ba71fa819e89502d14871af6dfc9693
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002543
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65809}
When reserving the requested virtual memory fails (due to address space
exhaustion), simply return nullptr to indicate allocation failure, which
callers must be prepared to handle anyway. That way, ClusterFuzz will
correctly classify OOM situations.
Bonus change: skip demo test on simulators to save time.
Drive-by cleanup: add a 'simulator_run' section to mjsunit.status
Bug: chromium:1042151,chromium:1042173
Change-Id: I8569f3c0d2a681fbf6f91b665dcb88a4ac3b901e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002391
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65785}
Tests which set the --perf-prof flag leave behind a file in the current
working directory every time they execute.
In order to avoid this, this CL introduces a --perf-prof-delete-file
flag, which removes this file right after creating it. This still allows
the process to write to it via the open handle, but the file will be
gone afterwards, even if the process crashes or gets killed while
executing.
R=ahaas@chromium.org
Bug: v8:10121
Change-Id: I99b159bb6d94255f77095ac78d98ba55106e94fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65759}
The fix in https://crrev.com/c/1997135 didn't properly recurse the cache
scope after a with scope, passing the current scope rather than the
original cache scope up the recursion. Now the "use external cache" check
is done in LookupWith (and, analogously, LookupSloppyEval) while passing
the given cache scope through the Lookup recursion.
Fixed: chromium:1041210
Fixed: chromium:1041616
Change-Id: I5ac9ddc6c16d63b59aa034721fccec2f7781c4f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000133
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65754}
TSan complains in "isolates" tests otherwise. Also further reduce
virtual memory requirements of the sample test to address flaky
allocation failures on 32-bit platforms.
Change-Id: I26c9a59965009d7083876b4ff4836ee879d33350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000138
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65750}
This reverts commit 304e97d334.
Reason for revert: Last roll is failing - https://ci.chromium.org/p/chromium/builders/try/linux-rel/282356
Original change's description:
> [parser] Fix caching dynamic vars on wrong scope
>
> When looking up a variable in a deserialized WITH scope, we were
> unconditionally passing in the cache scope to the lookup, even if the
> with was inside the cache scope. This would lead to and outer scope of
> the with holding the generated dynamic variable. If the cache scope was
> the SCRIPT scope, the dynamic variable would be interpreted as a global
> object property.
>
> Now, we only store the WITH scope dynamic variables in the cache scope
> if it is an inner scope of the WITH scope, same as we do for 'normal'
> scope lookups.
>
> Fixed: chromium:1041210
> Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65732}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: I7b6d77d03b603152a9a47541db466934f46b1176
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000140
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65747}
Rather than explicitly requesting MAP_HUGETLB mappings, which requires
kernel configuration, we should rely on the "Transparent Hugepages"
feature, where eligible allocation requests are automatically fulfilled
with huge page mappings.
Bug: chromium:1041232
Change-Id: I5263da7a23290316aa7b99e63881ca88e65b4e34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997442
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65741}
When looking up a variable in a deserialized WITH scope, we were
unconditionally passing in the cache scope to the lookup, even if the
with was inside the cache scope. This would lead to and outer scope of
the with holding the generated dynamic variable. If the cache scope was
the SCRIPT scope, the dynamic variable would be interpreted as a global
object property.
Now, we only store the WITH scope dynamic variables in the cache scope
if it is an inner scope of the WITH scope, same as we do for 'normal'
scope lookups.
Fixed: chromium:1041210
Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65732}
This patch contains real changes affecting the following tests:
- regress-1119: Bogus test, was failing justifiedly. Dropped.
- regress-crbug-9161: Was accidentally disabled everywhere. Re-enabled
for ASan (as the comment promised).
- regress-crbug-160010: Throws "invalid string length" on all platforms.
Was disabled everywhere. Dropped.
- regress-crbug-514081: Test was previously changed to use 2MB instead
of 2GB. Re-enabled variants.
Additionally, it reorders a bunch of definitions:
- Introduced separate sections for "mode == debug" and "no_i18n" to make
the "ALWAYS" section cleaner.
- Sorted various "slow tests", "open bugs", and "no_variants" definitions
into groups.
- Simplified long "arch == x or arch == y" sequences to "arch in (x, y)".
Bug: v8:10021
Change-Id: Ibe404ae400011196473cf082a4706ddbef7c8349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995390
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65718}
The regression test for crbug.com/976627 was:
(1) silently failing on all platforms,
(2) very brittle, baking in several internal limits,
(3) highly specific for one particular place in the code,
(4) when fixed, very slow: 6 seconds on x64.release.
For all these reasons, it is herewith dropped.
Bug: v8:10021
Change-Id: Ic144f6bfcca0c301f3aca7840edbdc43f34a77fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993975
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65715}
When Heap::TearDown is called, parts of the Isolate are already gone
(specifically: Managed<> objects, which includes Wasm NativeModules).
Since heap verification can depend on these parts (e.g. to find Code
objects belonging to current activations on the stack), we should do
it before tearing down things. Heap::StartTearDown is a suitable way
to achieve that.
Bug: v8:9209
Change-Id: I44094b19e16a4f372eb14ab363d8b4a65182f38a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993968
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65684}
This patch maintains the previous default value of the flag controlling
the max size of Wasm memories, but allows the limit to be raised on the
command line.
Bonus content: improve the multi-mapped mock allocator by falling back
to regular allocation for small requests.
More bonus content: make debug-mode Wasm tests faster.
Bug: v8:6306
Change-Id: Idabae5734794b06e65d45b3a6165dbd488847f3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981157
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65681}
This CL factors out the decision-making logic whether a property key should
be treated as a "property" or "element" into LookupIterator::Key, which can
be constructed on its own, allowing use sites to take this distinction into
account before constructing a LookupIterator from the Key, without needing
to duplicate the logic.
This also makes the assortment of LookupIterator constructors more uniform.
Bug: chromium:1031175
Change-Id: I81d7b11ab7e4915f5c05668138e6e0c51ae11821
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962272
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65672}
In the WebAssembly.Global constructor we continued to execute even after
the JavaScript code in the descriptor.mutable getter threw an exception.
This caused a problem when the descriptor.value getter was executed even
though there was a scheduled exception.
R=jkummerow@chromium.org
Bug: chromium:1033948
Change-Id: Idac554175fe45ec677447b793db069eb6de543b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993283
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65669}
This is a cleanup to remove unneeded flags after these changes (in
https://crrev.com/c/1988548):
* --future does not imply --wasm-tier-up any more, and
* --wasm-tier-up does not imply --liftoff any more.
Instead, now
* --wasm-tier-up is enabled by default,
* --wasm-tier-up has no effect if --liftoff is not set, and
* --future implies --liftoff.
R=ahaas@chromium.org
Bug: chromium:1040061
Change-Id: I5d04ee1f1d84ddcd0654df0e0a4c6298f80aee9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993280
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65666}
When FLAG_noconcurrent_recompilation is turned on we always run on main
thread. So it is safe to derefernce handles when printing the turbofan
graph. We should only add a DCHECK when dereferencing read-only heap
objects when optimizing concurrently.
Bug: chromium:1040444,chromium:1040403
Change-Id: I6bde966690458b1d122611b02e713c581c87f534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992433
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65659}
When parsing an arrowhead, it's possible for temporary variables to be
created with a different index depending on whether the parsing is lazy
or eager. This then results in bytecode mismatches as the index is used
to determine which register to use.
To make the ordering stable, this changes variable allocation in arrow
functions to always allocate the non-temporaries first and then the
temporaries.
Bug: chromium:1020162
Change-Id: Ia47c4c2916d63f12d20d663e4e3842bfd68f6d8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977865
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65657}
The optimized code for String.charCodeAt(BigInt.asUintN(64, 10n)) did
not throw a TypeError due to how lowering of CheckBounds triggers
RepresentationChanger.
Bug: chromium:1038573
Change-Id: Ie0f9ca95de5af5fd3701841ab169e11ccc77216c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986003
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65632}
During conflict detection, we want to early exit the scope loop when we
find a non-conflict, but continue looking at the other declarations in
the scope.
Bug: chromium:1038588
Change-Id: Ia2a19b02222fbd13cec70d3a60d2f5bae4ce245b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1985991
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65602}
The native context can differ from the current isolates
raw_native_context, so this DCHECK was never valid.
Bug: chromium:1033966
Change-Id: Iecbbdf33a8645ffd6e8768f4ba0eb0292eca269f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1982582
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65577}
If --perf-prof is specified, we commit the whole code range at once, and
never update the {total_committed_code_space_} counter (see
{WasmCodeManager::Commit} and {WasmCodeManager::Decommit}). Hence we
should also not decrement that counter when the native module dies.
R=jkummerow@chromium.org
Bug: chromium:1032753
Change-Id: I9a40f1a1322485d7142ed56f5c9365305aa0e056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969790
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65476}
Objects in arrays take the shape of the object right before as feedback to
speed up object creation. If a subsequent object with the same shape has a
member that also has the same shape, that member can cause the feedback map to
be deprecated. To avoid confusion, we now update (dedeprecate) the feedback map
before use.
Thanks a bunch Seth Brenith for figuring out the issue!
Bug: chromium:1029077
Change-Id: I047b1acfd4906616a2302f253ab9cd29272bdc79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1970211
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65474}
The {cmp} instruction might add an entry to the constant pool at a time
where we didn't expect any entries to be added.
This can be fixed by moving the {CheckConstPool} call *after* the {cmp}.
R=mslekova@chromium.org
Bug: chromium:1034394
Change-Id: If075ad0b02e2973a734d70d9e58c205bd14e6a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967380
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65463}
Bug: chromium:1029530
Change-Id: I12aa4c238387f6a47bf149fd1a136ea83c385f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962278
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65434}
With bytecode flushing and the current OSR triggering mechanism which
stores OSR nesting level on bytecode array it is possible to trigger
OSR on a closure that doesn't have feedback vector.
Bug: chromium:1031479
Change-Id: I4c62486f6b0eb6d6f9c96f98c1c1b275f3e6d6d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962850
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65431}
This reverts commit 026a0c214a.
Reason for revert: Reverting due to https://crbug.com/1029461
Original change's description:
> [parser] Fix variable caching for conflict lookup
>
> During conflict lookup (for lexical variables and sloppy block function
> hoisting), we cache the looked-up variable on the current scope if the
> lookup goes through a ScopeInfo. However, for variable lookup during
> scope analysis, we use the "entry point" as the cache.
>
> Since both lookups can create Variables, this can cause us to create
> duplicate variables, e.g. a duplicate function name variable in the
> attached test.
>
> Instead, for ScopeInfo conflict lookups we can cache the result on the
> function's outer scope, which shoud be equivalent to the entry point.
>
> As a (necessary) drive-by, we can terminate the lookup early if we find
> a VAR with the same name, as we can safely assume that its existence
> means that it doesn't conflict, which means that our variable can't
> conflict either.
>
> Bug: chromium:1026603
> Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65138}
TBR=leszeks@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1026603
Bug: chromium:1029461
Change-Id: Id7f5dd342e32e1bb57c51b3748feff32ee0ba41d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1958014
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65390}
In 5742da056a, the toString property was
accidentally applied to all NativeError prototypes, when it should only
be inherited from Error.prototype.
Refs: https://github.com/tc39/ecma262/issues/1794
Bug: v8:10017
Change-Id: I2af9a31f463deb9871dd7a4a5a2e4dd7485ed38c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933054
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65355}
Imports can also have associated names, and in fact we generate these
names for asm.js. Thus in logging, just append this name to the
generated signature.
R=jkummerow@chromium.org
Bug: chromium:1030103
Change-Id: I3969bcf8d1d17f4256b5a0643acdf8a24766f889
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948705
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65321}
Bug: chromium:1029576
Change-Id: If647f764da2682a0f278b9b8060d0665fab1c40c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948711
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65312}
CSA::TryLookupElement must check the upper bound for dictionary-mode
indices.
The "stable map + accessor" branch of FastGetOwnValuesOrEntries must
construct its LookupIterator such that it handles the named/indexed
distinction correctly.
Bug: chromium:1029338,chromium:1029369
Change-Id: I17e74ed24c260c5cfc20c61616e75db7d347f7a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1943164
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65301}
Loop variable analysis doesn't recognize that the initial type of the
loop variable phi combined with the increment type may produce a NaN
result through the addition of two infinities of differing sign.
This leads to unreachable code and a SIGINT crash.
The fix is to consider this case before typing the loop variable phi,
falling back to more conservative typing if discovered.
R=neis@chromium.org
Bug: chromium:1028863
Change-Id: Ic4b5189c4c50c5bbe29e46050de630fd0673de9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1946352
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65291}
Adding a regression test for https://crrev.com/c/1930606.
This test was generated using --dump-wasm-module, which created a 6KB
module, and then running binaryen's wasm-reduce on it until it churned
this out, and removing an extra kExprUnreachable.
Bug: chromium:1027410
Change-Id: I14ba6ebe52f45e3b3ba943088807e110eebe0339
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1933592
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65276}
Replacing a constant BigInt with a constant int64 is only valid
when the use site has truncating semantics. (For non-constant
values, the representation changer did correctly check for this.)
Bug: chromium:1028593
Change-Id: Ib58b16ece6f21ba30153fd6cfa0560cc2d78d6a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940263
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65262}
Reverting https://chromium-review.googlesource.com/c/v8/v8/+/1741660
This fixed one bug but caused a lot of others and on balance I think
reverting it is the lesser evil.
This also fixed generator-relocation.js because
(function*(){}).constructor is the function constructor and we try to
set a breakpoint on line 3.
Bug: chromium:109362, chromium:1028689
Fixes: v8:9721
Change-Id: I1bfe6ec57ce77ea7292df91266311f5c0194947e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940259
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65232}
This reverts commit 48c9ca4462.
Reason for revert: Possible clusterfuzz issues
Bug: chromium:1028952
Original change's description:
> [names] Fix some test262 name tests to conform with spec changes
>
> In order to reflect web reality, TC39 has made some slight changes to
> name descriptors, see https://github.com/tc39/ecma262/pull/1490 for
> details. V8 was mostly already in compliance with these changes, but
> ThrowTypeError and anonymous classes needed some slight changes.
>
> Bug: v8:9646
> Change-Id: I163238954938f0c005e3adbc61b90498e01436da
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Joshua Litt <joshualitt@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63373}
TBR=gsathya@chromium.org,joshualitt@chromium.org
Bug: v8:9646
Change-Id: I06dd5527d30052d9c9dfc45a2862be930274aba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939948
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65216}
Now since we also encode KeyedAccessStoreMode information in the slow
handler for some cases, the DCheck can result in failure.The Check can
result in failures for other cases of StoreSlow. Removing the DCHECK
altogether, now verifying the correctness of the behavior using the
Kind Bits of the Handler in the method GetKeyedAccessStoreMode.
Bug: chromium:1027025, chromium:1028085
Change-Id: I59acedbb499930e67ae5999d4bfd0f040a34b46e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1929408
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65185}
(1) One more place in ic.cc must guard against "lookup->name()" calls
when the LookupIterator might be in indexed mode.
(2) Rather than burdening LookupIterator users with specifying
"kGuaranteedNoTypedArray", we can do the corresponding calculation in
the LookupIterator itself, which makes it robust towards any callers
that haven't been updated (specifically, in Object.values).
Bug: chromium:1027461,chromium:1028213
Change-Id: I76b5d08e309fc2a694955b537adbeb5a30e681f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936474
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65177}
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}
During conflict lookup (for lexical variables and sloppy block function
hoisting), we cache the looked-up variable on the current scope if the
lookup goes through a ScopeInfo. However, for variable lookup during
scope analysis, we use the "entry point" as the cache.
Since both lookups can create Variables, this can cause us to create
duplicate variables, e.g. a duplicate function name variable in the
attached test.
Instead, for ScopeInfo conflict lookups we can cache the result on the
function's outer scope, which shoud be equivalent to the entry point.
As a (necessary) drive-by, we can terminate the lookup early if we find
a VAR with the same name, as we can safely assume that its existence
means that it doesn't conflict, which means that our variable can't
conflict either.
Bug: chromium:1026603
Change-Id: I19f80f65597ba6573ebe0b48aa5698f55e5c3ea1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928861
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65138}
FunctionBlueprint holds a SharedFunctionInfo, FeedbackVector and a
Hints object that represents what we know about the Context of
the "function-to-be." Since we occasionally synthesize a
FunctionBlueprint object from a JSFunction (when we have it),
it can happen that sometimes the Context hint is a concrete
Context object, and other times it's a VirtualContext, representing
a context created sometime during the bytecode execution of the
function under optimization. Moreover, both such FunctionBlueprints
can exist in the same run due to the vagaries of CALL_IC feedback
(ie, sometimes you have a JSFunction, other times you don't).
More details in doc:
https://docs.google.com/document/d/1F1FxoDzlaYP5l5T6ZcZacV3LCUp5elcez05KWj-Mp78/edit?usp=sharing
Bug: crbug:1024282
Change-Id: Id4055531333b3dcbdb93afd23d9a226728292e11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1926151
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65127}
This reduction relies on a known object layout of the regexp instance
in order to access the lastIndex field through a statically-determined
offset. Prior to this CL, we checked only for instance types, not for
the map, and thus it was possible to read garbage from either inside
or outside the current object.
Bug: chromium:1024758,v8:7779
Change-Id: I1eec8220797f443bdf3d05804e54f33b21fa2f00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924353
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65039}
Since WASM can generate direct calls to any function that it knows the
arity of and these can be any JS linkage builtin, we need to ensure that
CPP builtins also go into CODE_SPACE.
This moves 276 builtins (~25KiB) from RO_SPACE back to CODE_SPACE.
Bug: chromium:1022695, v8:7464
Change-Id: I4cda8b68ddf6a5ddad09c6e7d4e6a08c8e6c2ccb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916600
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65004}
When simulating bytecode, we store the current environment at the
site of the appropriate catch handler when entering a try range.
If the start of the try range is dead, we don't bother to store
an environment. However, generators can create alive regions
inside the try range. At such moments, we should recognize
we're in a try range and store the environment for the handler.
Bug: chromium:1017159
Change-Id: Icccc2ccf530895099bc62b97d9aaec8b97d5f4e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879247
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64929}
This allows the tests to continue running on the gc fuzzers while
staying compatible with the --force-slow-path flag being passed
randomly.
When run in slow_path variants these tests are no-ops, but that's
negligible as the tests are also fast without slow_path.
Change-Id: I461c47b669b163e1e1594ea1a941f63e90f2221e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910947
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64914}
... 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}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
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@{#64888}
When --always-promote-young-mc is enabled, this test becomes more
flaky. Increase old space size, such that objects fit into the
old generation during mark-compact.
Bug: v8:9192
Change-Id: Iad3b914c7d5b7bafa752f3b6178684a137bd8dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1890101
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64830}
