Negating the maximum int32 failed in ubsan. Use
{base::NegateWithWraparound} to avoid UB.
R=jkummerow@chromium.org
Bug: chromium:980007
Change-Id: If52a3bb3158eb5b465e7bd29deaffc0b18660360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683993
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62470}
This fixes undefined behavior in the implicit cast from double to float
when a double literal is passed through {fround} while declaring a local
variable.
R=jkummerow@chromium.org
TEST=mjsunit/regress/regress-crbug-976934
BUG=chromium:976934
Change-Id: I0efa2bf3f89d32c445f0b9bf719880d17fe9743c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683999
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62469}
crrev.com/c/1656852 Added an Array.reduce microbenchmark for frozen objects. On
Android devices, resources need to be whitelisted for loading.
This CL whitelists the missing resource file
R=bmeurer@chromium.org,verwaest@chromium.org
CC=duongn@microsoft.com
Bug: v8:9417
Change-Id: I0a2caca2eaaa769b085f28c3fede3a0c62d64754
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683994
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62468}
This reduces the time it takes to run this test in --jitless mode
from 32s to 0.7s.
Bug: v8:9416
Change-Id: Ie9a7465b604b28ff8ccaa50f0918c62e3128ac08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682575
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62464}
crrev.com/c/1653733 Added an Array.map microbenchmark for frozen objects. The
micro-benchmark is missing from the resource files. On Android devices,
resources need to be whitelisted for loading. The missing resource file is
causing the error in
https://chrome-swarming.appspot.com/task?id=45c1664eaeefd410
This CL adds the missing resource file
R=bmeurer@chromium.org,verwaest@chromium.org,duongn@microsoft.com
Bug: v8:9417
Change-Id: I66f8d989a1fafe5b2a357bdae7b3abd58ae54223
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682576
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62463}
Since https://codereview.chromium.org/2777583003, the Boyer-Moore
lookahead (used by the irregexp engine) also looks inside submatches
to narrow down its range of accepted characters at specific offsets.
But the end of a submatch, designated by a PositiveSubmatchSuccess
action node, was not handled correctly. When a submatch terminates,
we have no knowledge of what may follow, and thus must accept any
character at following positions. This is done by the SetRest call
added in this CL.
An example, since this is fairly obscure:
/^.*?Y(((?=B?).)*)Y$/s
The initial non-greedy loop, together with the s flag,
will trigger an attempted Boyer-Moore lookahead. After this follows
an unconditional Y, a *-quantified loop matching any char and
containing a lookahead that matches either 1 B or 0 B's, and an
unconditional trailing Y.
When the BM lookahead scans the subject string for the beginning of
this pattern after the non-greedy loop, it should look for: a Y at
offset 0, and either a B, a Y, or '.' (-> any character) at offset 1.
Prior to this CL this was not the case:
- The lookaround is internally generated as a submatch.
- The optional 'B?' is unrolled into 'either B followed by submatch
end' or 'submatch end'.
- Filling in BM infos terminates when encountering a submatch end.
Thus in the former case we added B to the set of accepted characters
and terminated, while in the latter case we simply terminated.o
This CL ensures that BM will accept any character at any offset at or
exceeding the first encountered submatch end.
Bug: v8:8770
Change-Id: Iff998ba307cd9669203846a9182798b8cf6a85dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679506
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Erik Corry <erikcorry@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62460}
regress-976627 is pass and should pass on mips64el,
see 4c15693https://crrev.com/c/1674027
Change-Id: I4da905ea129a78988d75e5b19cca3a4e5a17fdcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679960
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Yu Yin <xwafish@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62459}
The previous fix for this bug (crrev.com/c/1678365) pessimistically
would mark all shadowed variables as maybe_assigned. Unfortunately,
this doesn't work across a parse/preparse boundary, where the shadowing
variable is found via Scope::AnalyzePartially while the shadowed
variable is outside of the preparser entry point. In those cases, the
referencing proxy is copied to the outer scope, in which case the
dynamicness of the original lookup is lost and the maybe_assigned
pessimisation no longer applies.
This means that maybe_assigned status of a variable is dependent on
which function is being parsed. In particular, it can cause bytecode
to change on recompilation, causing issues for lazy source positions.
This patch allows SetMaybeAssigned to walk its shadowed variables,
and recursively set them to maybe_assigned too. Checking for
maybe_assigned changing prevents this recursion from having a
quadratic performance failure mode.
Bug: v8:8510
Bug: v8:9394
Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62458}
When applying Object.seal(), Object.freeze() to Smi, Double elements
kind, it will transition to Object elements kind first then to new
frozen, sealed elements kind accordingly.
Also, add more mjsunit.
Bug: v8:6831
Change-Id: I454b42d7eb329b03e20245896641eb6c1a87831d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662657
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62457}
Implement the spec change from the following TC39 PR:
https://github.com/tc39/ecma262/pull/1527
Bug: v8:9326
Change-Id: I9639903b12e7621e323990e2335f00e0313a59c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643171
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62451}
1. Move the reading of Notation before calling
SetNumberFormatDigitOptions()
( sync after https://github.com/tc39/proposal-unified-intl-numberformat/pull/37)
2. Sync SetNumberFormatDigitOptions to the spec.
3. Consider the case that while RoundingType is "compact-rounding"
do not set the precision.
4. correct the tests accordingly.
5. Fix the rounding of notation: "compact" and put regression cases
into test/intl/regress-9408.js
Bug: v8:9408
Change-Id: I78d66601fe21b1a74a50047b2abe6a2838a58b8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681599
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62450}
Measure speed regression of a range of char in complex regexp
The measurement is using the code from chromium:977003
To measure
python -u tools/run_perf.py --binary-override-path out/x64.release/d8 \
test/js-perf-test/RegExp.json
Run on three setting:
a. m74 based on tag 7.4.301
b. trunk (m77)
c. apply cl 1674851 on trunk
ComplexCaseInsensitiveTest-RegExp
Score is better if higher
Score imp % comp to m74
m74 22910
23430
23360
Trunk (m77) 15190 66.30%
15710 67.05%
15570 66.65%
CL 1674851 24590 161.88% 107.33%
24690 157.16% 105.38%
24200 155.43% 103.60%
Bug: chromium:977003
Change-Id: I7756f4739c44a07949103650565d1ca902e1b7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679651
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62449}
The latter is better because it takes field type into account when
decompressing field value.
Drive-by: use [DECL_]ACCESSOR macros for some fields.
Bug: v8:9353
Change-Id: I3d7f07d11b1e379e3e6cf0310d836af6b48c1338
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680539
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62444}
New Revision: 8b7ea912e516a6daa61487c700687a9426e3a396
Update v8 files / build config accordingly.
- There's now a new library in third_party/inspector_protocol,
bindings/bindings.h, which is configured much like encoding/encoding.h.
It doesn't have much stuff in it yet, but will soon get more code
that would otherwise need to go into jinja templates.
It also comes with a new test, only a smoke test thus far.
Change-Id: I9c00a54a840c214b4bb744a3b272e5ce221954fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678273
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62442}
This change is a partial implementation of Synthetic Module Record as specified here:
https://heycam.github.io/webidl/#synthetic-module-records
This includes:
- Introduce SyntheticModule class inheriting from Module.
- Extend v8::Module interface in v8.h to include Synthetic Module APIs, with corresponding
implementations in api.cc.
- Provide SyntheticModule implementations of PrepareInstantiate, FinishInstantiate, and SetExport.
- Provide cctest unit tests for the implementations in the preceding item.
We will follow up with further submissions to implement the remaining members of
SyntheticModule (ResolveExport and Evaluate).
Bug: v8:9292
Change-Id: I25b1b695b5d1c3004677cd685f0dfd95283438fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1626829
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62433}
GetPropertyWithReceiver is similar to GetProperty, except that additional receiver parameter is used in TryPrototypeChainLookup to support GetPropertyWithReceiver stub.
We only use this stub in ProxyGetProperty builtin for now.
Bug: v8:8958
Change-Id: Ied60e4f6ee6e09bca2f161048b481a0bf37a78a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676879
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62431}
powered by a new function Execution::CallWasm and a corresponding,
Turbofan-generated CWasmEntry stub. This entirely sidesteps the
traditional Execution::Invoke -> JSEntryStub path.
Change-Id: If2b97825cca4ce927eecbddc248c64782d903287
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660618
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62424}
d8 treats files with the .mjs extension as modules instead of
classic scripts. Thus, the `// MODULE` pragma and its corresponding
logic in test runners can be removed in favor of explicitly adding
the extension.
Bug: v8:7950, v8:9395, v8:9406
Also-By: tmrts@chromium.org
Change-Id: Ic74328dc5c5f176bb4bdf6d74bdd4d3966279ba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675958
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62421}
Currently, `intl/regress-7770` fails on environments with `LC_ALL`
set, e.g.
export LC_ALL=en_US.UTF-8
While engineers can manually work around it using `unset LC_ALL`
before running the test suite, it would be more convenient if the test
runner didn't rely on the absence of this environment variable in the
first place.
Bug: v8:8845
Change-Id: I8116e2fd369be1d561dfe465f2901d07d3f75510
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680538
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62417}
If there was an assignment to a maybe-shadowing dynamic variable,
then the shadowing variable would be marked maybe_assigned, but the
maybe-shadowed variable would stay unchanged. This meant that in
non-shadowing cases, the not-actually-shadowed variable would have
the wrong maybe_assigned state, and e.g. would break context
specialization.
This patch pessimistically unconditionally sets maybe_assigned on
variables shadowed by a dynamic variable in a `with` scope. This
marking can cause false positives and sub-optimal optimization for
some functions with 'with' blocks, but it's also the simplest fix
for this issue which doesn't affect performance in the common case
of no 'with' blocks.
Bug: v8:9394
Change-Id: I6924bd7d48dda61232aa9d72c39df1c76c665c67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678365
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62407}
This is a reland of 8de427fae8
Original change's description:
> [debugger] Expose reference to the function in debug-evaluate
>
> R=verwaest@chromium.org
>
> Bug: chromium:878723
> Change-Id: Ic07f75f15230018b6d19cd1ee21f4be6dcad6360
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667408
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62385}
TBR=jgruber@chromium.org
Bug: chromium:878723
Change-Id: I0386655a9b2632d2d9438e674d4205ce5e5365f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679490
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62401}
Just the low-hanging fruit. There is more to do.
Bug: v8:2487
Change-Id: Ia9afa32797960f6c4c7c4fa0f39c70efc63663e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669698
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62397}
Boilerplate values may possess an unboxed double field filled with the kHoleNan64Int sentinel value, which indicates that the field is uninitialized. When a boilerplate value migrates away from the unboxed double representation to a tagged one, we should replace the sentinel value by the proper uninitialized oddball value.
This fixes an issue with JSCreateLowering::AllocateFastLiteral not detecting const stores of uninitialized values properly.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: chromium:976598
Change-Id: I6bb216c0618a3105e6c8cfc04b1900d2f83a52ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674034
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#62394}
According to spec https://tc39.es/ecma262/#sec-object.preventextensions, the commit 8e0ef9b9a0 is missing the last step when object is proxy, it needs to return the object.
var proxy = new Proxy({}, {});
var object = Object.preventExtensions(proxy);
proxy === object; // should be true
Also, add mjsunit test.
Bug: v8:6664
Change-Id: Ic3688519539f8903ee0bc7e885905a86d195a4db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1668443
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62393}
This is a reland of 5ff38bae08
Original change's description:
> [TurboFan] Fast path for JSAdd with BigInt feedback
>
> This CL introduces the necessary infrastructure to generate speculative
> BigInt operations in case of BigInt feedback. In particular, the JSAdd
> operator is lowered to a speculative call to the BigIntAdd builtin,
> with a deopt bailout in case of exceptions or violated assumptions.
>
> Bug: v8:9213
> Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
> Commit-Queue: Nico Hartmann <nicohartmann@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62362}
Bug: v8:9213
Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Cr-Commit-Position: refs/heads/master@{#62381}
Deprecated maps might not be updated before being passed to
PrepareForDataProperty. If the target map is a dictionary map,
then adding the data property can fail.
As a drive-by, remove the dead ForTransitionHandler code, which
was another (potentially unsafe) caller of PrepareForDataProperty
Bug: chromium:977012
Change-Id: I894bbc9bca2001555474a3570eb03fe6b0f69ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674029
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62377}
There's no reason to use the API RegExp type instead of the internal
JSRegExp type. In fact, the parsed flags end up in
Runtime_CreateRegExpLiteral, which assumes them to be of type
JSRegExp::Flags.
Drive-by: Additional asserts and helper functions in JSRegExp.
Bug: v8:9359
Change-Id: I5c12aba7d4e39a4891fb23d8b47c55fc480a28d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667004
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62376}
In TurboFan, context specialization is an optimization that tries to
either replace the load of a value from the context with a constant,
or if that can't be achieved, at least reduce the hops up the
context chain by starting a walk to the required depth from the
first constant context that it can reach.
Currently, this optimization is performed by looking into the
heap during a reducer pass. With fully concurrent TurboFan, we
need to instead gather information about contexts we may want
to perform this optimization on during serialization.
This CL adds functionality to the serializer to recognize and
model operations that affect the context register. We add to the
hinting structure already used by the serializer. There is
a new type of hint: a VirtualContext. This is a tuple consisting
of a handle to a Context, and a distance field that indicates how
far away in a to-be-realized chain this VirtualContext sits from
the context in the handle. For example:
bytecode stream:
...
CreateBlockContext
...
After a block context is created, the accumulator now contains
a VirtualContext Hint with a distance of 1 from any context hints
that we are keeping track of in the current context register.
More details in the design doc here:
https://docs.google.com/document/d/1Y0LKKCEenLWyAZTetoAIpKTZRCxaNdkYV8X1GaCax2A/edit?usp=sharing
Change-Id: I63732ebd106cc138fb1e9789d0676ece63e15d27
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605941
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62370}
Large regexp results may exceed kMaxRegularHeapObjectSize and must
thus be allocated in large object space.
Drive-by: Rename '%InNewSpace' to '%InYoungGeneration'.
Bug: chromium:976627
Change-Id: I38b5aecb95a95cf2fdbb24d19550cec34361a09d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674027
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62368}
This reverts commit 5ff38bae08.
Reason for revert: flaky test that is not normally flaky failed.
See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531
Original change's description:
> [TurboFan] Fast path for JSAdd with BigInt feedback
>
> This CL introduces the necessary infrastructure to generate speculative
> BigInt operations in case of BigInt feedback. In particular, the JSAdd
> operator is lowered to a speculative call to the BigIntAdd builtin,
> with a deopt bailout in case of exceptions or violated assumptions.
>
> Bug: v8:9213
> Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
> Commit-Queue: Nico Hartmann <nicohartmann@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62362}
TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com
Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9213
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62364}
This CL introduces the necessary infrastructure to generate speculative
BigInt operations in case of BigInt feedback. In particular, the JSAdd
operator is lowered to a speculative call to the BigIntAdd builtin,
with a deopt bailout in case of exceptions or violated assumptions.
Bug: v8:9213
Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62362}
Perform a best-effort check for module context and provide an
appropriate error.
As seen from the import-blah-script.js test, we could have invalid
import expressions in a script context that could result in an error
saying "Cannot use import statement outside a module" which isn't
the ideal error because the error is an incorrect import
expression.
But, when the developer changes to a module context, the
correct error is thrown.
To fix this, we'd have to refactor and call ParseImportDeclaration,
and then throw an appropriate error, which seems like a lot of
overhead for not enough gain.
Bug: v8:9392, v8:6513
Change-Id: I520ebb490fff4d95743a7c751d4095db9a35d41b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675948
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62358}
testrunner assumes that each test suite has a single extension for base tests.
".mjs" extension can be used for ECMAScript modules in addition to the standard
extension ".js" we use for the base tests.
This CL generalizes the {TestLoader} to accept multiple extensions for
a single test suite.
R=mathias@chromium.orgTBR=machenbach@chromium.org
CC=gsathya@chromium.org
Bug: v8:9395
Change-Id: Ibc155f4963472fe9f989458cd839f3642ffbddea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675961
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62356}
This CL refactors the type-checking for br_table instructions.
Originally, we iterated over all targets of br_table and checked
if the values on the stack match the types expected by the
target's signature. However, this caused problems with type
checking unreachable br_table instructions where some stack
values are unavailable. According to the anyref proposal, the
expected type of br_table is the greatest lower bound of
all its targets. With the existing implementation, the expected
types were the types of the first target.
With this CL, we first calculate the expected types of br_table,
and only then inspect the stack if matching values are available.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I12208323bda88c363e28ffb0e002d59ef9a6b9d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649791
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62354}
This is a reland of 93b6c866f3
The bug that caused the test failures has been fixed in
https://chromium-review.googlesource.com/c/v8/v8/+/1667417
Original change's description:
> [csa] add hint to CAST error message to break in mksnapshot
>
> Change-Id: I51a22de5d6367c38056ea91eface4f69f6651993
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664069
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62274}
TBR=mvstanton@chromium.org, ulan@chromium.org
Change-Id: I7bb0b4237b6eada82456bc9cf2f293d5986f0d65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675954
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62353}
In this bug, we might replace a phi node with the Dead node even though
it still has uses. DeadCodeElimination picks this up and inserts a
runtime crash into the code.
Bug: chromium:974474
Change-Id: Iea685913c8666806972719bbfb0891e516207d4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669693
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62352}
Shared read-only heap means that all isolates within a process must
share the same snapshot. Pass the back-end snapshot to the front-end
runner to fix that.
Bug: v8:7464
Change-Id: I0ec591a919d4d462ef38e372907592df3c759521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669691
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62349}
This is a CL that aims to do a general cleanup of DecompressionElimination
to make it easier for devs to look at it, and to create new test cases.
Combined direct decompression & compression tests since they can be
summarized with a for loop in just one test that tries out
all the combinations.
Also created 'global' accesses to stop repeating them in every test.
Same for compression and decompression ops.
Added EXPECT in test cases that had none.
Added dots after comments.
Variables now use underscore instead of camelCase.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977, v8:7703, v8:9183
Change-Id: I38a5c6549e0b4ff89c3271ead23b626e8b6b4843
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628788
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62345}
We currently use the class name “JSValue” for JSObjects that wrap
primitive values. This name is a common source of confusion. This patch
switches to a name that’s more clear.
In addition to manual tweaks, the patch applies the following mechanical
global replacements:
before | after
--------------------------------|--------------------------------------
if_valueisnotvalue | if_valueisnotwrapper
if_valueisvalue | if_valueiswrapper
js_value | js_primitive_wrapper
JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE
JSPrimitiveWrapperType | JSPrimitiveWrapper type
jsvalue | js_primitive_wrapper
JSValue | JSPrimitiveWrapper
_GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62337}
We have a global test/OWNERS that has "file://COMMON_OWNERS".
This CL removes redundant OWNERS files in test/ subdirectories and
removes redundant entries from OWNERS files we need to keep for
special per-file entries.
R=yangguo@chromium.org, machenbach@chromium.org
CC=jkummerow@chromium.org
Bug: v8:9247
Change-Id: Ic2e8cbe8e379d7d23c86c6164305e65807f28ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674024
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62336}
We tried to pass the load mode even for stores.
Bug: chromium:977670
Change-Id: I2527a5ca755dba343b75f54383d17e22be0a20a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672940
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62333}
1. Check resources and not solely depend on res_index.res file
2. Performance is +2-3% for Collator, DateTimeFormat, Locale,
-2-3% for PluralRules, RelativeTimeFormat, ListFormat, NumberFormat
Consider we improve the performance x3 not long ago, these perf
regression could be ignored.
Bug: v8:9340
Change-Id: Iab7cd64a77a55a03aae40f4d477523c37b3bcd3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655978
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62322}
Calling FindIndexInScript performs a linear search on the script functions and can
take considerable time. With Bytecode flushing we will lose the function_literal_id
and have to call FindIndexInScript if we ever recompile the flushed function. This
can take a significant proportion of the recompilation time and has caused regressions
in rendering times for some web applications (e.g, 395ms in FindIndexInScript for 132ms
spent lazily re-compiling code).
To avoid this, add function_literal_id back into the SFI and remove it from
UnoptimizedCompileInfo. This will slightly regress memory usage (particularly
in cases where many of the SFIs are compiled), however it means we can remove
the FindIndexInScript function and avoid these long-tail regressions when
bytecode is flushed.
BUG=chromium:965833
Change-Id: Ia31e82eb6c871a6d698a518326a8555822a7a1d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669700
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62319}
Rework the implementation of non-external Torque classes to use
Struct machinery rather than FixedArray machinery. This allows
Torque-only defined 'internal' classes to the automatically generate
class verifiers and printers.
As part of this change, generate C++ boilerplate accessors for
internal Torque classes, since this is a pre-requisite for the
verifiers, printers and other Struct-based functionality.
Moreover, augment the header-generating functionality in Torque
to create separate header files for field offset definitions,
internal class C++ definitions and instance types.
Bug: v8:7793
Change-Id: I47d5f1570040c2b44d378f23b6cf95d3d132dacc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607645
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62317}
The table.copy instruction used the indirect_function_table_size field
of the instance for bounds-checks. However, when Table 0 is of type
anyref, this field is not set. Now we use the actual size of the table
instead.
R=clemensh@chromium.org
Bug: chromium:977101
Change-Id: Idda9cfe228141877747ed9a824936a1232f58cf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669695
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62315}
v8memory.h does not have V8 specific definitions, and having it in base
makes it clear that every component may include the file. It also
ensures that including it does not create spurious dependencies on
v8_base.
Change-Id: I565f63b25f33a9ada19d7b2ac5990863ab17f4a7
Bug: v8:9183, v8:8855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657923
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62309}
Adds basic support for CompressedHeapConstants to Arm64 by moving to a ldr_w
instruction and passing COMPRESSED_EMBEDDED_OBJECT as the RelocInfo. However,
we still haven't made the COMPRESSED_EMBEDDED_OBJECT be actually compressed
in the code-stream (they still take up a full 64-bits). Support for this will
be added next.
Adding a test on macro assembler that checks that the
RelocInfo::COMPRESSED_EMBEDDED_OBJECT is flowing through.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977, v8:7703, v8:9298
Change-Id: Ibc64cdfdd85d5cdfa060ed6227b10bb47eae3a8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635692
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62306}
Makes the order of the generated calls to the Runtime function
DefineAccessorPropertyUnchecked fixed regardless of hashseed so that
recompilation for lazy source positions always generates the same
result.
Moves AccessorTable from src/ast/ast.h to bytecode-generator.cc since
that's the only place that uses it.
Bug: v8:9383, v8:8510
Change-Id: I89e0aad1683a793714bfb48eca1b00abe20cad0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669689
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62303}
This is a reland of a5fa211f30
des_checksum and call_once_run were undefined and unused respectively when
shared read-only heap was enabled. Fixed with a copious amounts of USE.
Original change's description:
> [roheap] Check that ro-heap is always passed the same read-only snapshot
>
> Previously the ReadOnlyHeap simply discarded all but the first
> ReadOnlyDeseralizer. ClearSharedHeapForTest should be called if using a
> new ReadOnlyDeserializer (this might change in the future).
>
> Remove an obsolete 'StartupSerializerRootMapDependencies' test. It used
> to test Map::WeakCellForMap which doesn't exist anymore and was
> difficult to adapt to a shared read-only heap.
>
> Bug: v8:7464
> Change-Id: I64b8e953b0e3466e003541ec8a9321e439a01d33
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660612
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Cr-Commit-Position: refs/heads/master@{#62250}
TBR: yangguo@chromium.org
Bug: v8:7464
Change-Id: Id66e781be890c5ed03d066f8c62de703d5cb435e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667415
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62302}
The debugger should be notified whenever a new Module is created so it
displayed properly. Without this change, the Module is only displayed once,
regardless of the number of times it is referenced (by other Workers, say).
That is potentially reasonable behavior, but it doesn't match the way
JavaScript does it.
With this change, the debugger will display the sources like this:
```
▼ top
▶ localhost
▼ wasm
▼ wasm-82570336
wasm-82570336-0
▼ worker.js
▶ localhost
▼ wasm
▶ wasm-82570336
```
Change-Id: I61177e8a07e36ea8e2234aa25e75b1489c9da95f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666616
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62297}
Introduce SourceTextModule as a subclass of Module. Move all the
JavaScript-module-specific code down from Module to
SourceTextModule, with all code applicable to other future
module types remaining in Module.
With this change, Module is roughly equivalent to the spec's
Abstract Module Record and SourceTextModule is roughly equivalent
to Source Text Module Record.
Bug: v8:9292
Change-Id: I6e9cd3ece9d0c1da57e52f8af8ed5848d87dd22d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1633154
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62296}
This disallows using CSA macros from Torque that have a Node* return
type instead of TNode<>. By enforcing CSA types at the boundary between
CSA and Torque, we can ensure that the Torque types and the CSA types
match.
As a drive-by, this CL adds a bit more of CSA typing where it made sense.
Bug: v8:7793, v8:6949
Change-Id: I12ea0337c628105ea3c420be747ae50d3a172547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660481
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62293}
This patch implements the access of private methods:
- When building property loads, check whether it requires
a brand check. If so, build the brand check and load the
property (the method) from the context instead.
- Throw type errors when there is an attempted write to private
methods.
Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
Bug: v8:8330
Change-Id: Ic917d2a0030196c1940b0c0ba65a340af736c769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1610383
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62292}
A class's fields can appear twice in the class AST, via the properties
array and the synthetised initializer method. This means that the
reindexer can end up visiting the same function literal twice, since the
T in AST is no longer a T but rather a DAG.
Now, we special case the class visitor in the reindexer to avoid these
double visits where appropriate. We know what kinds of fields can be
double visisted, so we don't need a visited set, but we now also have
one for debug builds to verify that each function is visited exactly
once.
Bug: chromium:974627
Change-Id: Ib531becc6e3f3c73f420b5fb49790fe4a2022d65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667003
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62282}
Rather than starting a new, orphaned transition tree in various bailout
cases, simply drop down into dictionary mode.
Aside from potential memory benefits, this allows us to remove
CopyGeneralizeAllFields, which was the only path along which fields
could end up in a different order than their descriptors.
Change-Id: I5577e8a1ca51f0ffdadd7504e7895f367605aa27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662298
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62279}
This CL changes the generic version of Array#sort to use 'strict'
DeleteProperty when "moving" holes to the end of the sort range.
This brings V8 not only in line with the proposed Array#sort spec
change, but also closer to what other engines do. Now all engines
throw a TypeError when the new test case is run.
R=jgruber@chromium.org, mathias@chromium.org
Bug: v8:8714
Change-Id: Ic5bcd152ad55fd534c1e9e3218393bfe4a50667e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666995
Commit-Queue: Simon Zünd <szuend@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62273}
This CL fixes a flaky mjsunit test, that exercises Array#reduce with
sealed arrays in TurboFan. The flake was caused by temporary objects,
whos maps didn't live long enough. The code object of the function
under test holds weakly onto this maps. With a low enough gc interval,
the maps, and thus the code object, get cleaned up before the
{assertOptimized} can execute.
The fix is simply to assign these temporary objects to variables.
Bug: v8:9374
Change-Id: I43da8ba6b0194872b176e27617d9ca7fbfe43ec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666989
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62269}
CL https://chromium-review.googlesource.com/c/v8/v8/+/1660623
("[Turbofan] Brokerize more promise reductions in JSCallReducer")
introduced a bug where we bail out of a call reduction but failed
to remove graph constructs added by the MapInference class.
R=jarin@chromium.org
Bug: chromium:976256, chromium:976524
Change-Id: I97f142fe6c1caba5e679f7df742893536c83b2d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666990
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62267}
This reverts commit a5fa211f30.
Reason for revert: breaks ARM Lite builder:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/4843
Original change's description:
> [roheap] Check that ro-heap is always passed the same read-only snapshot
>
> Previously the ReadOnlyHeap simply discarded all but the first
> ReadOnlyDeseralizer. ClearSharedHeapForTest should be called if using a
> new ReadOnlyDeserializer (this might change in the future).
>
> Remove an obsolete 'StartupSerializerRootMapDependencies' test. It used
> to test Map::WeakCellForMap which doesn't exist anymore and was
> difficult to adapt to a shared read-only heap.
>
> Bug: v8:7464
> Change-Id: I64b8e953b0e3466e003541ec8a9321e439a01d33
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660612
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Dan Elphick <delphick@chromium.org>
> Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
> Cr-Commit-Position: refs/heads/master@{#62250}
TBR=yangguo@chromium.org,delphick@chromium.org,goszczycki@google.com
Change-Id: I099544913bec3bbd67840b1818a6ad6029fdf380
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666453
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62264}
For every @noVerifier in base.tq, this change either removes it or
ensures that it has some annotation explaining why it can't be removed.
The @noVerifier usages that can't be removed fall into the following
categories:
1. Classes that don't have their own instance types and therefore have
no meaningful way to do an Is...() check
2. Fields that might not exist
3. Fields that are waiting for MaybeObject support in Torque
Bug: v8:9311
Change-Id: Id452d4151ec07347ae96a9b5f3b26e2ac8065d31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659134
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62263}
This class used to be based on DispatchTable, which itself uses an
interval tree to both categorize and canonicalize ranges
(i.e. such that no overlap and all immediately adjacent ranges are
merged). The produced ranges were then entered into lists for
{bmp,lead_surrogate,trail_surrogate,non_bmp} splits.
With this CL, we simplify to a plain loop over all character range
kinds instead. The dispatch table (and ZoneSplayList, perhaps
SplayList) can be removed in follow-ups.
Bug: v8:9359
Change-Id: I9c6b72f3bc44d1557af7c74419709ae5662611f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664053
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62260}
Extract the maximum on-heap typed array size to a constant in the
JSTypedArray class. Add tests for allocating typed arrays of various
sizes and validate through the API whether they are allocated on heap.
It is not possible to observe from JavaScript.
R=mstarzinger@chromium.org
Change-Id: I1298e0a49010de829edaad32b7d6c6c9c52704fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662572
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62257}
Previously the ReadOnlyHeap simply discarded all but the first
ReadOnlyDeseralizer. ClearSharedHeapForTest should be called if using a
new ReadOnlyDeserializer (this might change in the future).
Remove an obsolete 'StartupSerializerRootMapDependencies' test. It used
to test Map::WeakCellForMap which doesn't exist anymore and was
difficult to adapt to a shared read-only heap.
Bug: v8:7464
Change-Id: I64b8e953b0e3466e003541ec8a9321e439a01d33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660612
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#62250}
We previously only optimized cases like
Parent <- Decompression <- Compression <- Child
to
Parent <- Child
This CL also adds the complementary optimization, namely, it reduces
Parent <- Compression <- Decompression <- Child
as above.
Such a cases became apparent after a recent extension of CSA load elimination (see https://chromium-review.googlesource.com/c/v8/v8/+/1660626), breaking a load elimination test case and thus the pointer compression build.
R=jarin@chromium.org, solanes@chromium.org
Change-Id: Ic730d05175f214e7055f94704141744ca44fefe5
Bug: v8:9353
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664070
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62246}
We don't want to handle even non-growing stores when there are TypedArrays
in the prototype chain. Typed arrays handle the out-of-bounds accesses by
ignoring the stores unlike the regular array writes. We just let runtime
handle these cases instead of making ICs more complex.
There was an earlier cl (https://chromium-review.googlesource.com/c/v8/v8/+/1609790)
that fixed it for growing stores. This cl extends it for non-growing stores
as well to handle more cases.
Bug: chromium:961709
Change-Id: I65e079b88c10d2ba343f69a67134893319cd8f8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662305
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62243}
This CL renames jsregexp.{h,cc} to regexp.{h,cc}, hides all non-public
functions of RegExpImpl in the .cc file, and renames the public parts
of RegExpImpl to just RegExp. Include directives from outside the
src/regexp directory are limited to regexp.h, regexp-stack.h, and
regexp-utils.h. We also expose all result codes that can be returned
by irregexp code (including RETRY) on the public header since they
are needed elsewhere, e.g. in builtins.
Bug: v8:9359
Change-Id: Iae1a01ac9f6e1e4dc168f3fbe8fe8679cb6b1259
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662297
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62240}
This is a reland of ac79b539ec
This CL adds a missing BlockPoolsScope to guard a RequestHeapObject
call. This fixes a latend bug that the original land flushed out.
Original change's description:
> [arm64] Refactor constant pool implementation
>
> This refactors the constant pool handling for arm64. The immediate goal
> is to allow 32bit compressed pointers in the pool. The mediate goal is
> to unify the implementation with the arm constant pool, which will be
> done in a follow-up CL.
>
> Bug: v8:8054
> Change-Id: I74db4245e5e1025f2e4de4144090fa4ce25883ab
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645316
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62209}
TBR=mstarzinger@chromium.org,jgruber@chromium.org,georgia.kouveli@arm.com
Bug: v8:8054
Change-Id: I1e3ab13619a48caad33d77ed8bed86782f9d9674
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664054
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62237}
This adds missing support when converting a Word32 value (either in
Signed32 or Unsigned32 range) to Word64 representation, for which the
type also includes MinusZero. This conversion is fine as long as the
difference between 0 and -0 is not observable (in other words, as long
as the truncation identifies zeros).
Bug: chromium:971782, chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: I9d350a25f57b1342eb7fd1279d55a8610bdaf7cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664062
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62235}
This CL allows CsaLoadElimination to retain some information in the presence of StoreToObject nodes. Two stores to an object don't alias if either the objects or the offsets don't alias. The analysis approximates either of these two conditions conservatively as follows:
- Freshly allocated, distinct objects cannot alias.
- Two objects cannot alias if one of is freshly allocated and the other was passed as a parameter or is a heap constant.
- Two offsets cannot alias if they are both constant and distinct from each other.
R=jarin@chromium.org, tebbi@chromium.org
Change-Id: Ibec81913b413f81a3f7cbd40544a22d3711e6e5a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1660626
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62232}
This change removes the special case in the Torque compiler for types
that descend from JSObject: they will no longer get implicit
"| Undefined" appended to their types for verification purposes. It
removes any additional custom verification steps in objects-debug that
are made redundant by that change.
In order to do so safely, I categorized all cases where we were
implicitly adding "| Undefined" to the field type, as follows:
1. Classes that aren't using the generated verifier function (we should
probably revisit these, but for now we at least know they're safe):
- JSGlobalObject
- JSFinalizationGroup
- JSFinalizationGroupCleanupIterator
2. Classes where the existing verifier is already at least as strict as
what we would get after removing the implicit "| Undefined":
- JSDate
- JSPromise
- JSRegExp
- JSRegExpStringIterator
- WasmMemoryObject
- JSWeakRef
- JSStringIterator
- WasmExceptionObject
- JSListFormat (fixed in part 1)
- JSPluralRules (fixed in part 1)
- JSRelativeTimeFormat (fixed in part 1)
- JSSegmenter (fixed in part 1)
- JSArrayBufferView (fixed in part 1)
- JSTypedArray (fixed in part 1)
3. Classes where, to the best of my knowledge based on code inspection,
we already initialize the object correctly to pass the new stricter
generated verifier:
- JSFunction
- JSArrayIterator
- JSMessageObject
- JSBoundFunction
- JSAsyncFromSyncIterator
- WasmModuleObject
- JSAsyncFunctionObject
4. Classes that needed some adjustment to their initialization order to
avoid exposing uninitialized state to the GC:
- JSArray (only in Factory::NewJSArray; Runtime_NewArray and
CodeStubAssembler::AllocateJSArray already behave fine)
- WasmTableObject
- JSDateTimeFormat
- JSNumberFormat
- JSCollator
- JSV8BreakIterator
- JSLocale
- JSSegmentIterator
- JSModuleNamespace
5. Classes that had incorrect type definitions in Torque:
- WasmGlobalObject (category 4 after correction)
6. Classes that weren't fully initialized due to bugs:
- JSGeneratorObject
- JSAsyncGeneratorObject
Bug: v8:9311
Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62228}
