Lowering does not work correctly for I64x2 and F64x2. Those tests are
guarded with X64, so it is fine, but if we remove the guard next
time, the failing tests will be confusing.
Bug: v8:8460
Change-Id: I98da0a2de1fefa8f46bdc5c0a1407973e3ed2b81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683928
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62494}
Introduce a helper class for regular expression parsing
and use it to improve load poison tests readability and
maintainability.
Extend load poisoning tests for arm64 platform (e.g.
for both regular and compressed references cases).
Change-Id: Ie62dfd14a60186feaa5f48e1a6122d77766472af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645913
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62493}
This is the first of three CLs which refactors indirect function calls
through tables with index > 0 to work without runtime calls.
The first CL introduces the WasmIndirectFunctionTable heap object. For
a table of type anyfunc within a WebAssembly instance,
WasmIndirectFunctionTable stores the size, the signature id's, the
call targets, and the reference parameters for that table. I used the
names that are already used for the matching fields of the
WasmInstanceObject.
The second CL expands the IndirectFunctionTableEntry to work also on
WasmIndirectFunctionTable objects. All changes to a function table go
through this class.
The third CL introduces uses of the WasmIndirectFunctionTable. In this
CL I change the code generation in TurboFan to replace runime calls with
direct accesses to the new WasmIndirectFunctionTable. Additionally I
extended the initialization of WasmIndirectFunctionTable, and also
implement Table.grow.
R=jkummerow@chromium.org
Bug: v8:7581
Change-Id: I0ecfcb9565e992ddba087d46c1f0e952abfa5822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681134
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62492}
Various TurboFan operators and builtins currently conflate the concept of a Unicode code point with that of its UTF-32 and UTF-16 encoding. UTF-16 is only used as an internal optimization, and should not be exposed. This CL separates affected operators and clarifies the naming of various internals.
Prior to this CL, StringCodePointAt operator's typing rule was unsound, since it was not strictly limited to returning values in the range of Unicode code points.
R=sigurds@chromium.org
Bug: v8:9413
Change-Id: Icd32fdbeceadbc74e9761b717a27e3ff9ecde1f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683998
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62490}
plus a test that calls a CAPI function directly from C++ (without
the detour through Wasm).
Anyref tables are still unsupported.
Change-Id: I450a6a75fde411da99691deab04c59a760a65a7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684076
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62489}
Operations on BigInts, for which TurboFan statically knows that they
are no larger than 2^64, can be lowered to efficient machine code
in TurboFan. This is the first step in doing so by generating
efficient code for asUintN and the required checks and conversions.
Bug: v8:9407
Change-Id: I51f6505f6c4567434fa369fcf870a09871487f51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680548
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@{#62488}
This is a reland of f23f644fb3
Fix the issue by wrap v8_executable("gen-regexp-special-case")
inside if (current_toolchain == v8_generator_toolchain) {
and change deps of action("run_gen-regexp-special-case")
to ":gen-regexp-special-case($v8_generator_toolchain)",
Original change's description:
> Speed up CharacterRange::AddCaseEquivalents
>
> By using the lexCss("color:") to measure the performance
> The change make the lexCss("color:")
> x21 - x40 times faster than trunk.
> x2.3 - x4.6 times faster than m74.
>
> Design Doc: http://shorturl.at/adfO5
>
> Measured by out/x64.release/d8 reg977003.js
> see reg977003.js attached to chromium:977003
>
> Also see another cl of benchmark in
> https://chromium-review.googlesource.com/c/v8/v8/+/1679651/
>
>
> Bug: chromium:977003
> Change-Id: Ie8518493d2c33df1594be1b4576bda715087b421
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674851
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62471}
Bug: chromium:977003
Change-Id: Ie690810f596e9551b5765f422665c9617391bcf8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683706
Reviewed-by: Frank Tang <ftang@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62486}
This adds a fast-path to inline `Math.hypot(v1,...,vn)` into optimized
code assuming that v1,...,vn are already numbers. The inlining follows
the general C++ implementation (which was also simplified a bit), and
thus uses Kahan summation to avoid rounding errors.
This improves the benchmark in [1] from around
testHypot: 656 ms.
testSqrt: 105 ms.
testExp: 103 ms.
to
testHypot: 147 ms.
testSqrt: 103 ms.
testExp: 102 ms.
so its roughly a **4.5x improvement**.
[1] 60a34c0dd2/bench-math-hypot.js
Bug: chromium:979893
Change-Id: Id834d5613bc22aa7ce27b9d6eca1f1f1979aa3e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684178
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62483}
test262 changes already merged in
9d0072df3d1897a63738b029b3e8d00df18d1201
but not roll into v8 yet.
Bug: v8:9327, chromium:980085
Change-Id: I0a97e1038ab8a68d439a78512ef513b3510478d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684703
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62482}
This mistake was introduced during big liveedit refactoring.
Reported in Node.js: https://github.com/nodejs/node/issues/28493R=dgozman@chromium.org,yangguo@chromium.org
Change-Id: Ic19984f1776dd5e0a25c6d7c41b4a7b7a9c76d22
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683101
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62479}
Change its name to InferReceiverMapsUnsafe and add a comment that
MapInference should be used instead in new code. There are two
remaining uses (outside of MapInference) and I'm not planning to
remove them.
TBR: jarin@chromium.org
Bug: v8:9197
Change-Id: I3c89f11bbf9b4eb3a1c6f1648c2046fe409fa830
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680540
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62477}
A folded allocation must fit into a regular (= non-large-object) heap
space. This CL changes AsyncFunctionEnter to allocate the
variable-sized fixed array separately from the folded JSPromise and
JSAsyncFunctionObject.
Bug: v8:9398
Change-Id: I9f3642e0bf060f7b61a42d6f490adbbb6d753ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684000
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62476}
Bug: v8:8460
Change-Id: Id159c81cd2d25924be96e49c64073e154ef32e6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667867
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62475}
Use it in String builtins in CSA and String, Array, Object builtins in Torque
Change-Id: I9c828cb1f5f04622470bb71317654cbe09305049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680648
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62473}
This reverts commit f23f644fb3.
Reason for revert: Breaks arm debug builder - https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug%20builder/22390 - missing file?
Original change's description:
> Speed up CharacterRange::AddCaseEquivalents
>
> By using the lexCss("color:") to measure the performance
> The change make the lexCss("color:")
> x21 - x40 times faster than trunk.
> x2.3 - x4.6 times faster than m74.
>
> Design Doc: http://shorturl.at/adfO5
>
> Measured by out/x64.release/d8 reg977003.js
> see reg977003.js attached to chromium:977003
>
> Also see another cl of benchmark in
> https://chromium-review.googlesource.com/c/v8/v8/+/1679651/
>
>
> Bug: chromium:977003
> Change-Id: Ie8518493d2c33df1594be1b4576bda715087b421
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674851
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62471}
TBR=adamk@chromium.org,jkummerow@chromium.org,yangguo@chromium.org,jshin@chromium.org,gsathya@chromium.org,ftang@chromium.org
Change-Id: I780fac2cf5f4bae6846f8d5c8765cabd76637545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:977003
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684073
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62472}
By using the lexCss("color:") to measure the performance
The change make the lexCss("color:")
x21 - x40 times faster than trunk.
x2.3 - x4.6 times faster than m74.
Design Doc: http://shorturl.at/adfO5
Measured by out/x64.release/d8 reg977003.js
see reg977003.js attached to chromium:977003
Also see another cl of benchmark in
https://chromium-review.googlesource.com/c/v8/v8/+/1679651/
Bug: chromium:977003
Change-Id: Ie8518493d2c33df1594be1b4576bda715087b421
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674851
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62471}
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}
Avoid inlining the {SmallVector::Grow} function, as it is rarely used.
This reduces binary size, since {emplace_back} is called a lot, and
often {emplace_back} itself is inlined.
As another minor tweak the {Grow} function now returns the new end of
the used storage, to reduce binary size in {emplace_back} even more.
Also, there is a separate version without argument.
R=mlippautz@chromium.org
Change-Id: If25f976649fee3f585b9a2cf6bdfe00fdb77af0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683995
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62467}
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}
This allows us to use this flag to specify the local location of a
shared library when processing a trace run on Android.
Change-Id: I3aa44beaed700b8c5354af12a4df176aa1cbfd0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681137
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62448}
for in the register allocation.
NOTE: This is expected to cause performance regressions, but we enable
it so that we can land small tweaks on top of it and get immediate
performance feedback.
Change-Id: I062f98a3ee6702509e870cc110096a3bdf53a6fd
Bug: v8:9088
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681133
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62447}
IWYU. This also fixes the libstdc++ build after commit 6056c0dc4a ("Make
adding crash keys thread safe"):
../../v8/src/diagnostics/crash-key.cc:36:15: error: no template named 'atomic' in namespace 'std'
static std::atomic<int> last{-1};
~~~~~^
Bug: chromium:957519
Change-Id: Ib1f465dc5e4f0b4a212486a9a3bebe54bb6654b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681129
Auto-Submit: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62446}
