- 03 Jul, 2019 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bd7f595..ce1ed5f Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2c75237..63f7fcc Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/dc37feb..f21ffb4 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/fb60bb4..686128d TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Change-Id: I8d4834c8a8faa3c5cb83eb3f8c793fbbaa7013d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687053Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#62497}
-
- 02 Jul, 2019 16 commits
-
-
Ng Zhi An authored
The test case SimdF32x4ExtractWithI32x4 was still passing when the codegen for F32x4Extract was entirely commented out. This change adds a new test cases that specifically exercises F32x4ExtractLane. It copies what is done in SimdI32x4SplatFromExtract, which involves moving the splatted and extracted values around locals, to ensure we move the values around registers and not unintentionally reuse registers that we splatted to, without actually extracting anything. Note that the existing SimdF32x4ExtractWithI32x4 is kept because it is used to test scalar lowering passes. Bug: v8:9420 Change-Id: Ieb883175b0e0139e8452c18f09d50b7dfb05a994 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684699 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Auto-Submit: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62496}
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I49c745f4dc2a97249621598ad0044c546638a9d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678402 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Ng Zhi An authored
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:
-
Artem Serov authored
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}
-
Andreas Haas authored
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/+/1681134Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#62492}
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I995996da621d84465d9bec4fc9e9d40308a92410 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683929Reviewed-by:
-
Sigurd Schneider authored
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}
-
Jakob Kummerow authored
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/+/1684076Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#62489}
-
Nico Hartmann authored
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:
-
Igor Sheludko authored
.. by using isolate-full accessors. Bug: v8:9353 Change-Id: I3b31c21df687e06f322d03daec4b9b532ac022d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683996Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62487}
-
Frank Tang authored
This is a reland of f23f644f 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/+/1683706Reviewed-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}
-
Michael Achenbach authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/f9c4d9d..bd7f595 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ac493ee..2c75237 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/788d9e0..dc37feb TBR=machenbach@chromium.org,sergiyb@chromium.org,tmrts@chromium.org Bug: chromium:980085 Change-Id: If86c3be92d4024526343defdea3b2d7d495e2eca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684154 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Yang Guo authored
R=machenbach@chromium.org Change-Id: I1e85df85e8eb588a0ae97320eba6e72163d9ff18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684175Reviewed-by:
-
Benedikt Meurer authored
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] https://github.com/bmeurer/js-micro-benchmarks/blob/60a34c0dd29b77e6950555c2dd9687b1a0a7671e/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:
-
Frank Tang authored
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:
-
Sigurd Schneider authored
Change-Id: I01199e24c4bb5d8496c13077342e03a41943cdbd Bug: v8:9088 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684074Reviewed-by:
-
- 01 Jul, 2019 23 commits
-
-
Johannes Henkel authored
New Revision: aec57d43b6a2c41c37fb0a2507108e89a9342177 This includes Junliang's fix for big endian. https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1680051 Bug: v8:9355 Change-Id: I21aa77b20bbaa3c897391a85cb1862f943c12e22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682607Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Alexei Filippov <alph@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#62480}
-
Aleksei Koziatinskii authored
This mistake was introduced during big liveedit refactoring. Reported in Node.js: https://github.com/nodejs/node/issues/28493 R=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:
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I0925f6ad9425b194a1274b14057cc6d36ce3dca1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1670169 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Reviewed-by:
-
Georg Neis authored
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:
-
Jakob Gruber authored
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:
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: Id159c81cd2d25924be96e49c64073e154ef32e6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1667867Reviewed-by:
-
Igor Sheludko authored
Create[Array|Object]Literal were simply extracted from Helper classes. Bug: v8:9353 Change-Id: I8a97a7d5151c324db4a924cbfe1720444a1529aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683992Reviewed-by:
-
Z Nguyen-Huu authored
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}
-
Maya Lekova authored
This reverts commit f23f644f. 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/+/1684073Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#62472}
-
Frank Tang authored
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: -
Clemens Hammacher authored
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/+/1683993Reviewed-by: -
Michael Starzinger authored
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/+/1683999Reviewed-by: -
Tamer Tas authored
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}
-
Clemens Hammacher authored
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/+/1683995Reviewed-by:Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62467}
-
Sigurd Schneider authored
Change-Id: I0dff07c33d55a3e1b8b16e095d771337c51876ba Bug: v8:9088 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682029Reviewed-by:
-
Deepti Gandluri authored
Change-Id: Ibc2d7a32bfd91e1db48735bbf49f86957cfbff11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680423Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
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:
-
Tamer Tas authored
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:
-
Georg Schmid authored
R=ishell@chromium.org, jarin@chromium.org, verwaest@chromium.org Bug: v8:9404 Change-Id: I7ec189340a77052cbdcb8e5802f7ac8197fafe10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680541Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#62462}
-
Nico Hartmann authored
Bug: v8:9213 Change-Id: I05f56f7bdd8d15f2ae992a97529fba18f0644c55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678417 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by:
-
Jakob Gruber authored
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:
-
Yu Yin authored
regress-976627 is pass and should pass on mips64el, see 4c156936 https://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:
-
Leszek Swirski authored
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:
-
