- 14 Dec, 2020 21 commits
-
-
Zhi An Ng authored
Change the codegen for f32x4.extract_lane from shufps to insertps. They have the same performance, but shufps has a false dependency on dst (it shuffles dst and src, but we don't care about dst at all). We then merge the SSE and AVX opcode. Bug: v8:11217 Change-Id: I7cdbf486573ce3a19881df84400a9c7e09c3ee48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585259Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71748}
-
Zhi An Ng authored
Change the codegen for f32x4.extract_lane from shufps to insertps when AVX is supported. They have the same performance, but shufps has a false dependency on dst (it shuffles dst and src, but we don't care about dst at all). Also for SSE, extractps + movd crosses register files, so change it to use insertps as well. Change-Id: Idf45849d37ac3499bf3371ba2fa6ae05829aa8a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589048 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
Zhi An Ng authored
This is the same as the original implementation in https://crrev.com/c/2567534 which was speculatively reverted due to flaky tests. Since then, there have been some changes to fix those tests, so trying to get this in again. Bug: v8:11002 Change-Id: I5bd0f63d3aec4cf6db403b35737f8b695b0f4e37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589063Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71746}
-
Milad Fa authored
Change-Id: I669eaed12f352398b8e34b1f74262f46562745cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2591047Reviewed-by:
Junliang Yan <junyan@redhat.com> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/master@{#71745}
-
Jakob Kummerow authored
This CL implements Liftoff support for struct.get/set, struct.new_with_rtt, rtt.canon, and ref.is_null, which is enough to make the first testcase pass. Bug: v8:7748 Change-Id: Id09e9872d2126127192c852b3cb6d57ff9417582 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584951 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71744}
-
Shu-yu Guo authored
Bug: chromium:1157692 Bug: chromium:1157386 Change-Id: I3525c5ea648bca6c2fb03bb910dbe9d673996da7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587603 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#71743}
-
Jan Krems authored
The original implementation of matching was a RegExp on the source which wasn't able to reliably distinguish between comments inside of string literals and actual comments. For that reason, it had a special rule to disallow quotes to remove false positives. Original comment: > Also, ['"] are excluded from allowed URLs to avoid matches > against sources that invoke evals with sourceURL. After the code was moved into the scanner, that shouldn't be an issue anymore - the scanner knows that this is a real comment and isn't part of a string literal. Allowing quotes enables a slightly smaller encoding of source maps, specifically in the case where there are no sourceContents: Non-base64 source maps can get away with effectively no encoding overhead (they typically don't contain whitespace). Change-Id: Iffa5df28d80656fa56e603e7c0e57aa1f44d0014 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2576801Reviewed-by:
Marja Hölttä <marja@chromium.org> Auto-Submit: Jan Krems <jankrems@google.com> Commit-Queue: Jan Krems <jankrems@google.com> Cr-Commit-Position: refs/heads/master@{#71742}
-
Thibaud Michaud authored
Only process each LiveRangeBundle once in AssignSpillSlots(). Previously we would try to merge a LiveRangeBundle as many times as there are LiveRanges inside it. Even though the merge would only happen once, we would still iterate over all LiveRanges and do expensive checks for each iteration. R=sigurds@chromium.org Bug: v8:11237 Change-Id: I9e613aaf5e571d4c28486dd2c20154336c533563 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584956 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#71741}
-
Michael Lippautz authored
Change-Id: Id6975d47665832feee23c528f457092385a5ec3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584958Reviewed-by:
-
Camillo Bruni authored
- Allow hiding individual timeline-tracks to clear up screen space. - Auto-hide timeline-tracks when there are no entries Bug: v8:10644 Change-Id: Ibde37242fa1fcb827ca176ee7576a23715c45bda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584954Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71739}
-
Nico Hartmann authored
This reverts commit 8ffbf0d2. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=1158322 Original change's description: > [TurboFan] Move SFI and BytecodeArray to kNeverSerialized > > This CL moves SharedFunctionInfo and BytecodeArray to the > kNeverSerialized classes, making them directly accessible from the > background thread. > > To resolve the dependence on HeapNumber and BigInt objects stored in > the BytecodeArray's constant pool, this CL introduces a new > ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows > for objects to be serialized lazily from the background thread where > we know that this is safe (e.g. because they are constant). BigInt and > HeapNumber are the first members of this new group of objects. > > Bug: v8:7790 > Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705 > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71716} TBR=neis@chromium.org,nicohartmann@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: Ice35d7c1c4d7e96be887a0aa26fbfa69db627022 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589734Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71738}
-
Junliang Yan authored
Change-Id: I232585076ecf6a824cdbe2e989eadaf96adcc1d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587241Reviewed-by:
Milad Fa <mfarazma@redhat.com> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#71737}
-
Junliang Yan authored
Change-Id: I9ee0113cf28b8f4c25a73b970877e5353cbf2076 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586151Reviewed-by:
-
Milad Fa authored
Simd128Registers::names_ is also removed as the stringification will be done by DEFINE_REGISTER_NAMES. PPC FP and Vector Register (VR and VSR) Layou: VR0 is VSR32 and goes all the way to VSR63 which is used by V8 Vector operations. VSR[0]0 - FPR[0] VSR[0]128 | | | VSR[31] - FPR[31] VSR[32] - VR[0] VR[0]128 | | | V VSR[63] - VR[31] Change-Id: Ied2a530b08d1eb40af59ce44f848d638f2a6dc9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587356Reviewed-by:
-
LiuYu authored
Port: 6dbc2b01 Bug: v8:10975 Change-Id: Id3e70dda9f71ecf333890e70d6a5e64ed5a91ccf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2575731Reviewed-by:
Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Auto-Submit: Liu yu <liuyu@loongson.cn> Cr-Commit-Position: refs/heads/master@{#71734}
-
Jakob Kummerow authored
Switch from an array of supported types to a switch over type kinds, in preparation for user-defined reference types. Bug: v8:7748 Change-Id: I17a0a71184ee0937748f07f22c1fd545a057fb6e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584950 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71733}
-
Camillo Bruni authored
Associate DeoptLogEntry with both, the function's source position and the deopt location's source position. Also fixes the list-panel click handler to support all clickable entry types. Bug: v8:10644, v8:10754 Change-Id: If10272a926d5dad10b29322e237610900715b9dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584955 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
-
Camillo Bruni authored
- Show selection tab-bar - Hide panels on empty timeline - Fix legend position in ic list-panel Bug: v8:10644 Change-Id: I4ef09627ed4de8682adb60f88be38867bc91640d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584953Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/62841ca..b0341eb TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I819de0f3557de321ad8426eb7205bce56f4b4196 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2588956Reviewed-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@{#71730}
-
Zhi An Ng authored
Drive-by cleanup: IWYU for macro-assembler-ia32.cc. IWYU added src/heap/basic-memory-chunk.h which failed a presubmit, so I updated src/DEPS to allow for including it. Bug: v8:11217,v8:7490 Change-Id: I63662bfb2b34e354e94f6052edfcb92f1341da58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583675Reviewed-by:
-
Zhi An Ng authored
Drive-by cleanup: IWYU for macro-assembler-ia32.h and instruction-selector-ia32.cc Ran using `iwyu_tool.py -p out/ia32.debug <filename>`, with a local build of llvm and iwyu. Bug: v8:11217,v8:7490 Change-Id: I4f8e95fa9be2f51f6764c994bb4da9ae86854c4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2583671Reviewed-by:
-
- 13 Dec, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/11901ee..62841ca Rolling v8/third_party/aemu-linux-x64: VSu8Vtf9AtE1W0EtQ4GMhLufzBudMRrz3_8vRSuj0O4C..ijHjc7kfgeuh7rvjQtk93a5SuvO23dABp_CeotpPcMAC TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: I9ab3d4ef52ac1a8edcf8f18b7fc6786de0da66bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2588394Reviewed-by:
-
- 12 Dec, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/026aa68..11901ee Rolling v8/third_party/aemu-linux-x64: 5qqsaI1HWopoPDYdsXSJnZ-4w5bARXjJgFX_oohbDqIC..VSu8Vtf9AtE1W0EtQ4GMhLufzBudMRrz3_8vRSuj0O4C Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d5e2194..0991ca1 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c94b21d..99399ca TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com Change-Id: Iff37157907d9d7a0fc8c28fbd839ffc9695da4f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587792Reviewed-by:
-
- 11 Dec, 2020 17 commits
-
-
Junliang Yan authored
Change-Id: I083a15e0a25668e149f832477c9bef0963993696 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587353Reviewed-by:
-
Junliang Yan authored
Change-Id: I59c905182294dc4e8fb8caf03f10ea66d332e034 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586153Reviewed-by:
-
Milad Fa authored
Change-Id: Id9a8f9d7a7ccf7dc85a140ed3da30f429fc073ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2587008Reviewed-by:
-
Milad Fa authored
PPC has a set of 64 Vector Registers called VSX. The lower 32 of them are shared with Floating Point register (only 64 bit of the registers are used for FP operations). The upper 32 registers are VR registers which are only used for VMX Vector operations. VSX Vector operations have the option to use the lower 32 or upper 32 registers using the TX bit set on the instructions. VMX operations only use the upper 32 registers. In V8 we always set the VSX TX bit to "1" to make sure all the vector operations take place on the upper 32 registers. Change-Id: Ib3ea03254cbdc9547c3b698fe19c0c6b28138741 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2585260 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
-
Jakob Kummerow authored
This flag disables the implicit fallback to Turbofan when Liftoff bails out due to an unsupported instruction/type. Instead, Liftoff bailouts are treated as fatal errors. This is meant for testing; it is not (yet?) a configuration we support in production. Change-Id: I04e2045f1976e202e65da0ba8e8d660c47859bf4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584949Reviewed-by:
-
Junliang Yan authored
Change-Id: I6d7e263b84d6871cb13cb01b2b51299b9249d961 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586994Reviewed-by:
-
Clemens Backes authored
The rest of the code base was already migrated last year in https://crrev.com/c/1631409. In the API we have to be more careful to not break embedders. According to the standard there is no semantic difference between typedef and using ([decl.typedef#2]): A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword becomes a typedef-name and the optional attribute-specifier-seq following the identifier appertains to that typedef-name. Such a typedef-name has the same semantics as if it were introduced by the typedef specifier. Thus this CL replaces all typedefs in include/v8.h by the equivalent using declaration. This improves readability, especially for function pointer types. R=ulan@chromium.org CC=leszeks@chromium.org Bug: v8:11074 Change-Id: Id917b6aa5c8cd289c60bda5da1e3667e747936e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563880 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#71719}
-
Clemens Backes authored
The name has very few uses. I found at least one where the current value does not make sense (on js-to-wasm wrappers in profiling), but I found zero uses that were actually useful. Hence this CL removes the name, i.e. just sets none on wasm scripts. R=thibaudm@chromium.org, yangguo@chromium.org Bug: chromium:1125986 Change-Id: I2f793986a3da905980132cd09349dd6a1d787957 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584245 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#71718}
-
Junliang Yan authored
Change-Id: I9761b80f32beeb53e466fc67ee1c535075e4225c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2586993Reviewed-by:
-
Nico Hartmann authored
This CL moves SharedFunctionInfo and BytecodeArray to the kNeverSerialized classes, making them directly accessible from the background thread. To resolve the dependence on HeapNumber and BigInt objects stored in the BytecodeArray's constant pool, this CL introduces a new ObjectDataKind::kPossiblyBackgroundSerializedHeapObject, which allows for objects to be serialized lazily from the background thread where we know that this is safe (e.g. because they are constant). BigInt and HeapNumber are the first members of this new group of objects. Bug: v8:7790 Change-Id: I1d962d1cb7c36cc3f5baeb9603d5298f32af3363 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567705Reviewed-by:
Georg Neis (ooo until January 5) <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#71716}
-
Peter Marshall authored
I think this was likely fixed by one of the other bugfixes in the meantime. It doesn't flake with 50k runs locally. Fixed: v8:2008 Change-Id: I9e6f1e7f75cf20c52d49937d980aafacaa23b401 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584945Reviewed-by:
-
Thibaud Michaud authored
The issue is with this pattern, assuming disjoint uses for all vregs: phi: v1 = v0 ... phi: v2 = v0 ... phi: v3 = v0 ... ... phi: vN = v0 ... For every phi, BuildBundles proceeds as follows: - Create a new bundle for the output - Merge the input bundle into the output bundle Since the bundle gets bigger at every iteration, the merges become more and more expensive and consume Zone memory that is immediately thrown away at the next iteration. A simple fix is to check the size of the bundles before merging and always copy the smallest one into the biggest. In the pattern above this should always copy the single-range output bundle into the large input bundle. R=sigurds@chromium.org Bug: v8:11237 Change-Id: I6ad9152035da698d94b02b5b41802545ba149307 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584879Reviewed-by:
-
Manos Koukoutos authored
When Liftoff bails out, the function ExecuteLiftoffCompilation performs an early return before updating the "counters" data structure with the bailout reason. The early return was introduced in https://chromium-review.googlesource.com/c/v8/v8/+/2423710. We should just drop it again, as there is another "if (did_bailout()) return" right after updating the counters. Bug: v8:11259 Change-Id: Ia7f72c3a7eda4252a5a4450646427edb26130996 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584880Reviewed-by:
-
Omer Katz authored
The gc_in_progress flag was reset to false only after sweeping was done. As a result, if we call CollectGarbage during an incremental GC and after marking has finished, the we will observe that a gc is still in progress but will not have a marker and crash. The immediate solution is to move resetting the gc_in_progress flag such that it indicates whether we didn't have the atomic pause yet. That means we could have gc_in_progress==false and incremental sweeping still running, which semantically negates the meaning of gc_in_progress. Observing that gc_in_progress essentially becomes equivalent to having a marker, this CL removes the gc_in_progress flag and replaces checks on it with checks on marker. Bug: chromium:1156170 Change-Id: Ic4b441ec248b5f7e222e988870e46d5166dd4dcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584875 Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71712}
-
Liviu Rau authored
Using the config of one of the builders that catched the chromium:1138115 issue; compile only. Bug: chromium:1142484 Change-Id: I4ad19a7c32819a3a8306fa169d3c8ec0ffb47a8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584874 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71711}
-
Anna Henningsen authored
Add a method that returns the microtask queue that is being used by the `v8::Context`. This is helpful in non-monolithic embedders like Node.js, which accept Contexts created by its own embedders like Electron, or for native Node.js addons. In particular, it enables: 1. Making sure that “nested” `Context`s use the correct microtask queue, i.e. the one from the outer Context. 2. Enqueueing microtasks into the correct microtask queue. Previously, these things only worked when the microtask queue for a given Context was the Isolate’s default queue. As an alternative, I considered adding a way to make new `Context`s inherit the queue from the `Context` that was entered at the time of their creation, but that seemed a bit more “magic”, less flexible, and didn’t take care of concern 2 listed above. Change-Id: I15ed796df90f23c97a545a8e1b30a3bf4a5c4320 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2579914Reviewed-by:
-
Mythri A authored
next_enumeration_index is the next free index available to store a property. ObjectDescriptor tracks this field while instantiating the literal and updates the next_enumeration_index when finalizing the instantiation. When adding new properties (named / computed) we were updating this value to the current value that is being used instead of next free index. This cl fixes it. Bug: chromium:1152231 Change-Id: Ica8c36dcabf035db559e29d4573ecd5e53d6062a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2577463 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71709}
-
