- 23 Jan, 2019 1 commit
-
-
Mike Stanton authored
Change-Id: I3a60be25b9c7daadcad6078447348b790b249e1c Reviewed-on: https://chromium-review.googlesource.com/c/1402774 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59042}
-
- 21 Jan, 2019 1 commit
-
-
Simon Zünd authored
This CL adds a stack check to the TFS builtin "FlattenIntoArray" as it is called recursively and can cause a SEGV with a large enough "depth" argument. R=jgruber@chromium.org Bug: v8:8708 Change-Id: I833506531bcff1c4703b9a21678028cf0e63638d Reviewed-on: https://chromium-review.googlesource.com/c/1424858 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58952}
-
- 08 Jan, 2019 1 commit
-
-
Mike Stanton authored
Change-Id: Ifc71ae885b2a08b898ace7f75a8df0ca2b9c3a3d Reviewed-on: https://chromium-review.googlesource.com/c/1275820 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#58643}
-
- 27 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: I54b857cdacf9360b95d64147a486a0d5fa1ffe10 Reviewed-on: https://chromium-review.googlesource.com/c/1388526 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58473}
-
- 19 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: Iebb60551a461304539d943a080ce107eecf6fdbf Reviewed-on: https://chromium-review.googlesource.com/c/1384264Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58371}
-
- 12 Dec, 2018 1 commit
-
-
peterwmwong authored
InternalPackedArray now only has one constructor variant that expects no arguments (Chrome's only usage of InternalPackedArray). As such, these TFC builtins are no longer used and were removed: - InternalArrayNoArgumentConstructor_Holey - InternalArraySingleArgumentConstructor_Packed - InternalArraySingleArgumentConstructor_Holey On x64.release, this reduces builtins size by ~1.2KB. Bug: v8:7624 Change-Id: I7316608dc02b1e09e9e414ee1aeb1fb08410c6f6 Reviewed-on: https://chromium-review.googlesource.com/c/1372772 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58193}
-
- 11 Dec, 2018 1 commit
-
-
Ben L. Titzer authored
This is purely a renaming change. The ES spec uses the term 'detach' for the process of removing the backing store of a typed array, while V8 uses the historical term 'neuter'. Update our internal implementation, including method names and flag names, to match the spec. Note that some error messages still use the term 'neuter' since error messages are asserted by some embedder tests, like layout tests. R=bmeurer@chromium.org, yangguo@chromium.org, mstarzinger@chromium.org, mlippautz@chromium.org BUG=chromium:913887 Change-Id: I62f1c3ac9ae67ba01d612a5221afa3d92deae272 Reviewed-on: https://chromium-review.googlesource.com/c/1370036 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#58149}
-
- 04 Dec, 2018 1 commit
-
-
Marja Hölttä authored
For this to work, I had to move PropertyCell out of objects.h too, since otherwise there would be an inl include cycle which makes the code not compile. BUG=v8:5402,v8:8238 Change-Id: I3233f86b68c1e2fd32d135fcf0bbba8101af8cb2 Reviewed-on: https://chromium-review.googlesource.com/c/1356510Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#58004}
-
- 27 Nov, 2018 1 commit
-
-
Daniel Clifford authored
Change-Id: I57e21c5bc754ca07f52032f85ec8aeff96448dd0 Reviewed-on: https://chromium-review.googlesource.com/c/1342929 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57855}
-
- 26 Nov, 2018 1 commit
-
-
Daniel Clifford authored
In the process, use the correct ArrayPrototype* naming convention for the slice and splice builtins. Change-Id: I1f85e5512dbde8f92e7c764aef9f137d0a6693e0 Reviewed-on: https://chromium-review.googlesource.com/c/1350869Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57840}
-
- 20 Nov, 2018 1 commit
-
-
Tobias Tebbi authored
This enables more seamless interop between Torque and CSA: Since CodeStubAssembler can now inherit from the Torque base namespace, macros defined in the base namespace can be used in CodeStubAssembler macros, even without qualification. At the same time, macros in the base namespace can refer to CodeStubAssembler macros. The only new limitation is that types defined in code-stub-assembler.h cannot be referenced in the signature of macros defined in the base namespace, since this would produce a cyclic header dependency. A work-around for this woud be to put such types (like int31 in this CL) into a separate header included by both. I (mis-)used code-assembler.h for that. Another side-effec is that types and enums defined in CodeStubAssembler have to be accessed in a qualified way from Torque. Other assemblers can now inherit from their Torque equivalent, so porting macros into the corresponding Torque namespace doesn't require any change to the existing use-sites. To avoid C++ ambiguities, the Torque-generated assemblers must not define anything also defined in Code(Stub)Assembler. This includes the type aliases for TNode, PLabel, ... My workaround is to qualify everything in the generated C++. As a drive-by fix, I had to change the formatter to avoid a situation where it doesn't compute a fixed point: putting a keyword at the beginning of a line removes the '\s' in front of it, so I replaced that with '\b'. Bug: v8:7793 Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041 Reviewed-on: https://chromium-review.googlesource.com/c/1341955Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
-
- 19 Nov, 2018 2 commits
-
-
Tobias Tebbi authored
Bug: v8:7793 Change-Id: I4ce0008f56976102bad952ef2389f40845dcc15b Reviewed-on: https://chromium-review.googlesource.com/c/1340255Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57605}
-
Jakob Gruber authored
In preparation for converting these stubs to builtins. This turns the compile-time IsJSArray parameter into a runtime check. Bug: v8:7777 Change-Id: Ief44e7cd77e772809e50618e55f51268e9ac8ad9 Reviewed-on: https://chromium-review.googlesource.com/c/1339868 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57594}
-
- 15 Nov, 2018 1 commit
-
-
Georg Neis authored
This might have enabled our fuzzing to find the recent bug. R=bmeurer@chromium.org Bug: v8:8449 Change-Id: Iaa485061e132a9d20b995478dd9a642e2224f435 Reviewed-on: https://chromium-review.googlesource.com/c/1337588Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57541}
-
- 13 Nov, 2018 2 commits
-
-
peterwmwong authored
Previously, the following call sequence was always made when creating resulting subsetted TypedArray: 1) TFJ TypedArrayPrototypeSubArray 2) TFS TypedArrayConstructor 3) TFS CreateTypedArray This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is safe to use (IsPrototypeTypedArrayPrototype and !IsTypedArraySpeciesProtectorCellInvalid). Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement... BEFORE TypedArrays-SubarrayNoSpecies(Score): 1033530 TypedArrays-SubarrayNoSpecies(Score): 1018490 TypedArrays-SubarrayNoSpecies(Score): 1037030 AFTER TypedArrays-SubarrayNoSpecies(Score): 1439030 TypedArrays-SubarrayNoSpecies(Score): 1417540 TypedArrays-SubarrayNoSpecies(Score): 1405980 Bug: v8:7161 Change-Id: I356dace36570aa161ffe208a57a80e46714121a2 Reviewed-on: https://chromium-review.googlesource.com/c/1331154 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57458}
-
Georg Neis authored
It's not sufficient to check the NoElements protector because that doesn't guard against the array having a custom prototype. Bug: v8:8449 Change-Id: I843815466a1e4ae197a2b76eec62d04cdc2d619d Reviewed-on: https://chromium-review.googlesource.com/c/1332232Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57457}
-
- 09 Nov, 2018 1 commit
-
-
Daniel Clifford authored
It sould take an exception argument to ensure the proper re-throw semantics. Change-Id: I36caba1a80c0d3f59c18dce5a58a0c1f0100657d Reviewed-on: https://chromium-review.googlesource.com/c/1328803 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57401}
-
- 06 Nov, 2018 1 commit
-
-
Jakob Gruber authored
This condition is easy to miss at call sites and could create 'fast' arrays that are too large. Let's make this a runtime CHECK instead. Bug: chromium:901944 Change-Id: I8f8f161781414944b67099007a98f76972496ae2 Reviewed-on: https://chromium-review.googlesource.com/c/1319571Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57281}
-
- 05 Nov, 2018 2 commits
-
-
Georg Neis authored
This is a reland of 7bd9eb7e. No changes to that patch other than adding a test case. The bug that lead to the revert has been fixed in 9bf8f72c. Original change's description: > Add fast paths to Array.from. > > This reuses the fast path from IterableToList for Array.from. The fast > paths are taken when .from is called with the receiver Array and the only > argument is the iterable (no mapping function or thisArg). > > Bug: v8:7980 > Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746 > Reviewed-on: https://chromium-review.googlesource.com/c/1297322 > Commit-Queue: Hai Dang <dhai@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56993} Bug: v8:7980 Change-Id: Id081837946c0989ec2b31ce991f48d09e0219b09 Reviewed-on: https://chromium-review.googlesource.com/c/1317586Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57240}
-
Tobias Tebbi authored
No longer use inheritance to associate Torque-generated assemblers with corresponding CSA subclasses. Instead, all references to CSA and CSA-derived assemblers are now explicitly qualified, by generating a short-lived assembler instance in-place. As a consequence, Torque files have to mention the assembler external macros live in. The CodeStubAssembler is the default for this and can be omitted. As a drive-by cleanup, also distinguish between names that are emitted in C++ and names that are intended to be read in error messages. This is relevant for generic instantiations, where the generated names are rather unreadably mangled. As a follow-up, it will be easy to allow for qualified access to different modules, thus implementing full namespace semantics for modules. Bug: v8:7793 Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950 Reviewed-on: https://chromium-review.googlesource.com/c/1309636 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57235}
-
- 02 Nov, 2018 1 commit
-
-
Adam Klein authored
This reverts commit 7bd9eb7e. Reason for revert: crashes on canary, see https://crbug.com/901010 Original change's description: > Add fast paths to Array.from. > > This reuses the fast path from IterableToList for Array.from. The fast > paths are taken when .from is called with the receiver Array and the only > argument is the iterable (no mapping function or thisArg). > > Bug: v8:7980 > Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746 > Reviewed-on: https://chromium-review.googlesource.com/c/1297322 > Commit-Queue: Hai Dang <dhai@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56993} TBR=neis@chromium.org,dhai@google.com Bug: v8:7980, chromium:901010, v8:8410 Change-Id: I5e73267f0b3a905582c57a6fad1459c031600a73 Reviewed-on: https://chromium-review.googlesource.com/c/1315935 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#57221}
-
- 31 Oct, 2018 2 commits
-
-
Daniel Clifford authored
This is preparation to support the Torque port of Object.fromEntries, including tests to make sure that the interface of the iterator functions is correct and compiles when used. Change-Id: I2a30ef80a80f42d4744a92746c8cd383abc10c19 Reviewed-on: https://chromium-review.googlesource.com/c/1303726 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57192}
-
Tobias Tebbi authored
Bug: chromium:899029 Change-Id: I0fc724d5c77e5cbf2580de53f48934ae6f968934 Reviewed-on: https://chromium-review.googlesource.com/c/1310196Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57189}
-
- 30 Oct, 2018 1 commit
-
-
Jakob Gruber authored
Until this CL, CSA array allocation methods only handled arrays that could fit into new space. This behavior was preserved in a bunch of related builtins (e.g. Array.p.map), which completely bailed out to the slow path if larger allocations were required. This CL adds large object space handling to array allocation functions, which means that callers can use the more permissive kMaxFastArrayLength boundary instead of kInitialMaxFastElementsArray. Bug: chromium:890599 Change-Id: Idabb0ef232c2896cd453e2ae10b479bf24cbb1c1 Reviewed-on: https://chromium-review.googlesource.com/c/1301483 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57124}
-
- 26 Oct, 2018 1 commit
-
-
Jakob Gruber authored
Tbr: ishell@chromium.org Bug: v8:8238 Change-Id: I3fe3b821105d2ce58df717970085098f6336f937 Reviewed-on: https://chromium-review.googlesource.com/c/1301512Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57039}
-
- 25 Oct, 2018 1 commit
-
-
Hai Dang authored
This reuses the fast path from IterableToList for Array.from. The fast paths are taken when .from is called with the receiver Array and the only argument is the iterable (no mapping function or thisArg). Bug: v8:7980 Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746 Reviewed-on: https://chromium-review.googlesource.com/c/1297322 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56993}
-
- 24 Oct, 2018 2 commits
-
-
Mathias Bynens authored
Spec: https://tc39.github.io/ecma262/#sec-array.of Note that the `IsConstructor` abstract operation [1] is implemented as a `typeswitch`. [1] https://tc39.github.io/ecma262/#sec-isconstructor Bug: v8:8321 Change-Id: I17af918c1d928faf8a630b35432876baa96da217 Reviewed-on: https://chromium-review.googlesource.com/c/1296464Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
-
Tobias Tebbi authored
In preparation of porting Array.of to Torque, restructure the code and add Construct() and ArrayCreate() to match spec text. As a drive-by change, add and improve a bunch of CSA types and remove direct usage of JSConstruct. Bug: v8:8321 Change-Id: I445093388214d5b17b6dbc8d24c76ee296163071 Reviewed-on: https://chromium-review.googlesource.com/c/1296487Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56928}
-
- 18 Oct, 2018 1 commit
-
-
Hai Dang authored
Change-Id: Ic7d90d479b090670339200e4b6255fb1fb2441a5 Reviewed-on: https://chromium-review.googlesource.com/c/1288352Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#56770}
-
- 11 Oct, 2018 1 commit
-
-
Mike Stanton authored
A new CSA function, MoveElements() does an efficient memmove operation when the ElementsKind or new-space status allows it. A few other TNode cleanups applied in the file, for example, preferring the StoreFixedDoubleArrayHole() function. Change-Id: Ia0848c066eebbbbe321f81afe0cfa7df7567cbb7 Reviewed-on: https://chromium-review.googlesource.com/c/1268235 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56567}
-
- 28 Sep, 2018 1 commit
-
-
Daniel Clifford authored
This CL adds a bit more rigor to the handling of length properties in JSObject-derived classes that explicitly contain that property inline. This involves: - Introducing a new superclass of JSArgumentsObject called JSArgumentsObjectWithLength that is shared with other object instances that also have a fixed length property. - Adding JSArgumentsObjectWithLength to the type hierarchy in Torque, including adding fast-cases for leading the length property for all classes deriving from JSObjectWithLength. - Adding more rigor to Context and NativeContext handling in base.tq. This is useful for the map checks required to verify objects are argument object types derived from JSArgumentsObjectWithLength. Change-Id: I2f0a20601ffcb90b3767cbaeb766e9998d3462ec Reviewed-on: https://chromium-review.googlesource.com/1248661 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56289}
-
- 25 Sep, 2018 1 commit
-
-
Hai Dang authored
This fast path copies the backing store and replaces holes with undefined. In the case where the array is holey but there is no actual holes, the resulting array is of the same elements kind as the source array. If a hole does appear, the resulting array will be of PACKED_ELEMENTS kind so that it can contain undefined. The builtin CloneFastJSArrayFillingHoles includes this fast path, but CloneFastJSArray does not (it still behaves as before). In case of fast packed arrays, CloneFastJSArrayFillingHoles behaves the same as CloneFastJSArray. Bug: chromium:881273, v8:7980 Change-Id: I49c641c1a673313f06aeed93077031ab6b017b6d Reviewed-on: https://chromium-review.googlesource.com/1236573 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56209}
-
- 21 Sep, 2018 1 commit
-
-
Jakob Kummerow authored
GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class either derives from a class or has a member field of a type that was declared in an anonymous namespace. It is also opposed (-Werror=attributes) to visibility attributes being defined at explicit template instantiations. GCC 8.x further has reservations (-Werror=class-memaccess) about letting memset/memcpy modify areas within non-POD objects. Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a Reviewed-on: https://chromium-review.googlesource.com/1208306 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56106}
-
- 20 Sep, 2018 1 commit
-
-
Igor Sheludko authored
and introduce RootsTable - a V8 heap roots storage. So, the renaming part looks like this: Heap::RootListIndex -> RootIndex Heap::kBlahBlahRootIndex -> RootIndex::kBlahBlah Bug: v8:8015, v8:8182 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I38e1f3e3f6813ef35e37b0bed35e9ae14a62134f Reviewed-on: https://chromium-review.googlesource.com/1234613Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#56067}
-
- 18 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This is the next step to support large array buffers. On 64-bit archs the full safe integer range is available (up to 2^53-1 bytes in theory). On 32-bit platforms the full Unsigned31 range is allowed, so that we can continue to use CheckBounds for typed arrays and data views in the optimizing compiler (it's generally unlikely that the kernel will give you more than 1GiB of contiguous memory anyways). Drive-by-fix: This introduces proper chokepoints for the byte_offset and byte_length accesses in the CSA code, and also does some renaming for consistency. Bug: v8:4153, v8:7881, v8:8171 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e Reviewed-on: https://chromium-review.googlesource.com/1228377Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56008}
-
- 10 Sep, 2018 1 commit
-
-
Simon Zünd authored
This CL fixes a bug that allowed calls to Array.p.shift on zero-length arrays where the 'length' is read-only without throwing a TypeError. R=bmeurer@chromium.org, jgruber@chromium.org Bug: chromium:882233 Change-Id: Ib129ab4c4f4f233e7bb553effa77539badfbe26e Reviewed-on: https://chromium-review.googlesource.com/1215164Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55746}
-
- 05 Sep, 2018 1 commit
-
-
Hai Dang authored
This is a reland of 1c48d52b. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
-
- 23 Aug, 2018 3 commits
-
-
Simon Zünd authored
This is a reland of 9e48a24f Original change's description: > Reland "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" > > The CL was reverted because it broke some tests in ChromeOS. > > > [array] Move Array.p.sort to Torque and use TimSort instead of QuickSort > > > > This CL changes the sorting algorithm used in Array.p.sort from > > QuickSort to TimSort (implemented in Torque). > > > > Detailed performance results can be found here: https://goo.gl/4E733J > > > > To save on code space, fast-paths are implemented as sets of > > function pointers instead of specializing generics. > > > > R=cbruni@chromium.org, jgruber@chromium.org > > > > Bug: v8:7382, v8:7624 > > Change-Id: I7cd4287e4562d84ab7c79c58ae30780630f976de > > Reviewed-on: https://chromium-review.googlesource.com/1151199 > > Commit-Queue: Simon Zünd <szuend@google.com> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#55003} > > Bug: v8:7382, v8:7624 > Change-Id: Ic7a3230f3708177774b0760f08b7659d83ec5505 > Reviewed-on: https://chromium-review.googlesource.com/1184901 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55325} Bug: v8:7382, v8:7624 Change-Id: I297611f45c09967e0f6961156b0c9ebdebc7053f Reviewed-on: https://chromium-review.googlesource.com/1186801 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#55360}
-
Maya Lekova authored
This reverts commit 9e48a24f. Reason for revert: Possibly breaking the V8-Blink Mac bot - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Mac/15097 Original change's description: > Reland "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" > > The CL was reverted because it broke some tests in ChromeOS. > > > [array] Move Array.p.sort to Torque and use TimSort instead of QuickSort > > > > This CL changes the sorting algorithm used in Array.p.sort from > > QuickSort to TimSort (implemented in Torque). > > > > Detailed performance results can be found here: https://goo.gl/4E733J > > > > To save on code space, fast-paths are implemented as sets of > > function pointers instead of specializing generics. > > > > R=cbruni@chromium.org, jgruber@chromium.org > > > > Bug: v8:7382, v8:7624 > > Change-Id: I7cd4287e4562d84ab7c79c58ae30780630f976de > > Reviewed-on: https://chromium-review.googlesource.com/1151199 > > Commit-Queue: Simon Zünd <szuend@google.com> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#55003} > > Bug: v8:7382, v8:7624 > Change-Id: Ic7a3230f3708177774b0760f08b7659d83ec5505 > Reviewed-on: https://chromium-review.googlesource.com/1184901 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55325} TBR=jgruber@chromium.org,szuend@google.com Change-Id: Ie7e2af57a6480aa0504ba21ec98ee825d7ac74fe No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7382, v8:7624 Reviewed-on: https://chromium-review.googlesource.com/1186601Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#55355}
-
Simon Zünd authored
This reverts commit f4ca3fc5. Reason for revert: Since TF (js-call-reducer) calls into the C++ builtin, it is easier (cleaner for now) to implement the baseline version in C++ instead of Torque. Original change's description: > [array] Prepare Array.p.shift for removal of the JavaScript fall-back > > This CL changes the ArrayPrototypeShift builtin to a CSA macro which > is used in a newly created Torque builtin. > > This is in preparation for removing the JavaScript fall-back, which > will be replaced by a baseline Torque implementation. > > R=cbruni@chromium.org, jgruber@chromium.org > > Bug: v8:7624 > Change-Id: I9b7898beea2802cc02d394e040a1e500387cf108 > Reviewed-on: https://chromium-review.googlesource.com/1169172 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Simon Zünd <szuend@google.com> > Cr-Commit-Position: refs/heads/master@{#55036} TBR=cbruni@chromium.org,jgruber@chromium.org,szuend@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7624 Change-Id: I4929eefaa90ff8681bc8ae20e3ea3fe84ee7f1e8 Reviewed-on: https://chromium-review.googlesource.com/1186342Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55345}
-