AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
ec2f4acf4b
v8/src/builtins/base.tq

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1368 lines
51 KiB
Plaintext
Raw Normal View History

Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
[torque] make C++ includes explicit Bug: v8:7793 Change-Id: I12aae5d61a21f3e6e010e07622fe0d01a5ba03eb Reviewed-on: https://chromium-review.googlesource.com/c/1344118 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#58052}
2018-12-05 16:34:57 +00:00
#include 'src/builtins/builtins-utils-gen.h'
#include 'src/builtins/builtins.h'
#include 'src/code-factory.h'
#include 'src/elements-kind.h'
#include 'src/heap/factory-inl.h'
#include 'src/objects.h'
#include 'src/objects/arguments.h'
#include 'src/objects/bigint.h'
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type Arguments constexpr 'CodeStubArguments*';
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
type void;
type never;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
type Tagged generates 'TNode<Object>' constexpr 'ObjectPtr';
type Smi extends Tagged generates 'TNode<Smi>' constexpr 'Smi';
[torque] add union types This adds support for union types to Torque. There is a new type expression A | B to form the union of the type expressions A and B. This is only possible if A and B have a common supertype, to prevent nonsensical unions of types with different representations. Union types are normalized: A | B == B | A A | (B | C) == (A | B) | C A | A == A The subtyping rules are defined recursively: (A | B) <: C if A <: C and B <: C A <: (B | C) if A <: B or A <: C This allows to define Object as a union type: type Tagged generates 'TNode<Object>'; type Smi extends Tagged generates 'TNode<Smi>'; type HeapObject extends Tagged generates 'TNode<HeapObject>'; type Object = Smi | HeapObject; The type {Tagged} is introduced to have a common supertype of all tagged values, but we should not use it directly, because {Object} contains the additional information that there is nothing but {Smi} and {HeapObject} values. When mapping union types to CSA types, we select the most specific common supertype. For Number and Numeric, we already use union types on the CSA side. Since it is not possible to map to CSA union types in general, we special-case these two union types to map them to the CSA union types we already use. Bug: v8:7793 Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908 Reviewed-on: https://chromium-review.googlesource.com/1076132 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53411}
2018-05-29 13:31:56 +00:00
type HeapObject extends Tagged generates 'TNode<HeapObject>';
Fix formatting of Torque union types Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50 Reviewed-on: https://chromium-review.googlesource.com/c/1297949 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56937}
2018-10-24 11:28:28 +00:00
type Object = Smi | HeapObject;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
type int32 generates 'TNode<Int32T>' constexpr 'int32_t';
type uint32 generates 'TNode<Uint32T>' constexpr 'uint32_t';
[dataview] Move DataView floating point getters to Torque This CL moves the DataViewGetFloat32 and DataViewGetFloat64 getters from runtime to Torque. Change-Id: Ic85ec7bcb4e48f679c24e28121b7c543454e7cde Reviewed-on: https://chromium-review.googlesource.com/1088919 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53606}
2018-06-07 08:02:33 +00:00
type int64 generates 'TNode<Int64T>' constexpr 'int64_t';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type intptr generates 'TNode<IntPtrT>' constexpr 'intptr_t';
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
type uintptr generates 'TNode<UintPtrT>' constexpr 'uintptr_t';
[dataview] Move DataView floating point getters to Torque This CL moves the DataViewGetFloat32 and DataViewGetFloat64 getters from runtime to Torque. Change-Id: Ic85ec7bcb4e48f679c24e28121b7c543454e7cde Reviewed-on: https://chromium-review.googlesource.com/1088919 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53606}
2018-06-07 08:02:33 +00:00
type float32 generates 'TNode<Float32T>' constexpr 'float';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type float64 generates 'TNode<Float64T>' constexpr 'double';
type bool generates 'TNode<BoolT>' constexpr 'bool';
[builtins] Port GetArgumentsFrameAndCount to Torque In the process, add the bint type (which stands for Best-INTeger), which implements Torque's idea of CSA's ParameterMode. It maps to a different type on 32-bit (Smi) and 64-bit (intptr). There are convert operators that are either no-ops or conversions to-and-from Smi and intptrs on the each platform, depending on the underlying type for bint. This allows Torque code to git most of the benefits of ParameterMode without having to explicitly pass around the mode, since it is almost always OptimalMode anyways. Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162 Reviewed-on: https://chromium-review.googlesource.com/c/1361160 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@{#58253}
2018-12-14 19:35:34 +00:00
type bint generates 'TNode<BInt>' constexpr 'BInt';
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
type string constexpr 'const char*';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
type int31 extends int32
generates 'TNode<Int32T>' constexpr 'int31_t';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type RawPtr generates 'TNode<RawPtrT>' constexpr 'void*';
[torque] implement function pointers to builtins This CL adds the new type expression builtin(Context, ArgType1, ...) => ReturnType and allows to use Torque-defined builtins as values of this type, as well as calling values of this type. The new function pointer types are subtypes of Code. Change-Id: Ib7ba3ce6ef7a8591a4c79230dd189fd25698d5b9 Reviewed-on: https://chromium-review.googlesource.com/1060056 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53217}
2018-05-16 14:00:35 +00:00
type AbstractCode extends HeapObject generates 'TNode<AbstractCode>';
type Code extends AbstractCode generates 'TNode<Code>';
[nojit] Change builtin pointers to use Smis underneath This changes Torque's builtin pointers to use a Smi representation underneath instead of storing the Code target object. Callsites look up the target entry point through IsolateData::builtin_entry_table. The notable effect of this CL is that builtin pointer calls no longer call any on-heap Code. Bug: v8:7777 Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63 Reviewed-on: https://chromium-review.googlesource.com/c/1379880 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58286}
2018-12-17 13:41:53 +00:00
type BuiltinPtr extends Smi generates 'TNode<BuiltinPtr>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type JSReceiver extends HeapObject generates 'TNode<JSReceiver>';
Port Array.of to Torque 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/1296464 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
2018-10-24 09:31:21 +00:00
type Constructor extends JSReceiver generates 'TNode<JSReceiver>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type Context extends HeapObject generates 'TNode<Context>';
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
type NativeContext extends Context generates 'TNode<Context>';
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
type String extends HeapObject generates 'TNode<String>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type Oddball extends HeapObject generates 'TNode<Oddball>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type HeapNumber extends HeapObject generates 'TNode<HeapNumber>';
Fix formatting of Torque union types Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50 Reviewed-on: https://chromium-review.googlesource.com/c/1297949 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56937}
2018-10-24 11:28:28 +00:00
type Number = Smi | HeapNumber;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
type BigInt extends HeapObject generates 'TNode<BigInt>';
Fix formatting of Torque union types Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50 Reviewed-on: https://chromium-review.googlesource.com/c/1297949 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56937}
2018-10-24 11:28:28 +00:00
type Numeric = Number | BigInt;
[torque] add union types This adds support for union types to Torque. There is a new type expression A | B to form the union of the type expressions A and B. This is only possible if A and B have a common supertype, to prevent nonsensical unions of types with different representations. Union types are normalized: A | B == B | A A | (B | C) == (A | B) | C A | A == A The subtyping rules are defined recursively: (A | B) <: C if A <: C and B <: C A <: (B | C) if A <: B or A <: C This allows to define Object as a union type: type Tagged generates 'TNode<Object>'; type Smi extends Tagged generates 'TNode<Smi>'; type HeapObject extends Tagged generates 'TNode<HeapObject>'; type Object = Smi | HeapObject; The type {Tagged} is introduced to have a common supertype of all tagged values, but we should not use it directly, because {Object} contains the additional information that there is nothing but {Smi} and {HeapObject} values. When mapping union types to CSA types, we select the most specific common supertype. For Number and Numeric, we already use union types on the CSA side. Since it is not possible to map to CSA union types in general, we special-case these two union types to map them to the CSA union types we already use. Bug: v8:7793 Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908 Reviewed-on: https://chromium-review.googlesource.com/1076132 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53411}
2018-05-29 13:31:56 +00:00
type JSProxy extends JSReceiver generates 'TNode<JSProxy>';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type JSObject extends JSReceiver generates 'TNode<JSObject>';
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
type JSArgumentsObjectWithLength extends JSObject
generates 'TNode<JSArgumentsObjectWithLength>';
type JSArray extends JSArgumentsObjectWithLength
generates 'TNode<JSArray>';
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
// A HeapObject with a JSArray map, and either fast packed elements, or fast
// holey elements when the global NoElementsProtector is not invalidated.
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
transient type FastJSArray extends JSArray
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
generates 'TNode<JSArray>';
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
// A FastJSArray when the global ArraySpeciesProtector is not invalidated.
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
transient type FastJSArrayForCopy extends FastJSArray
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
generates 'TNode<JSArray>';
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
// A FastJSArray when the global ArrayIteratorProtector is not invalidated.
transient type FastJSArrayWithNoCustomIteration extends FastJSArray
generates 'TNode<JSArray>';
[builtins] Port GetArgumentsFrameAndCount to Torque In the process, add the bint type (which stands for Best-INTeger), which implements Torque's idea of CSA's ParameterMode. It maps to a different type on 32-bit (Smi) and 64-bit (intptr). There are convert operators that are either no-ops or conversions to-and-from Smi and intptrs on the each platform, depending on the underlying type for bint. This allows Torque code to git most of the benefits of ParameterMode without having to explicitly pass around the mode, since it is almost always OptimalMode anyways. Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162 Reviewed-on: https://chromium-review.googlesource.com/c/1361160 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@{#58253}
2018-12-14 19:35:34 +00:00
type SharedFunctionInfo extends HeapObject
generates 'TNode<SharedFunctionInfo>';
[torque] add union types This adds support for union types to Torque. There is a new type expression A | B to form the union of the type expressions A and B. This is only possible if A and B have a common supertype, to prevent nonsensical unions of types with different representations. Union types are normalized: A | B == B | A A | (B | C) == (A | B) | C A | A == A The subtyping rules are defined recursively: (A | B) <: C if A <: C and B <: C A <: (B | C) if A <: B or A <: C This allows to define Object as a union type: type Tagged generates 'TNode<Object>'; type Smi extends Tagged generates 'TNode<Smi>'; type HeapObject extends Tagged generates 'TNode<HeapObject>'; type Object = Smi | HeapObject; The type {Tagged} is introduced to have a common supertype of all tagged values, but we should not use it directly, because {Object} contains the additional information that there is nothing but {Smi} and {HeapObject} values. When mapping union types to CSA types, we select the most specific common supertype. For Number and Numeric, we already use union types on the CSA side. Since it is not possible to map to CSA union types in general, we special-case these two union types to map them to the CSA union types we already use. Bug: v8:7793 Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908 Reviewed-on: https://chromium-review.googlesource.com/1076132 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53411}
2018-05-29 13:31:56 +00:00
type JSFunction extends JSObject generates 'TNode<JSFunction>';
[builtins] Port GetArgumentsFrameAndCount to Torque In the process, add the bint type (which stands for Best-INTeger), which implements Torque's idea of CSA's ParameterMode. It maps to a different type on 32-bit (Smi) and 64-bit (intptr). There are convert operators that are either no-ops or conversions to-and-from Smi and intptrs on the each platform, depending on the underlying type for bint. This allows Torque code to git most of the benefits of ParameterMode without having to explicitly pass around the mode, since it is almost always OptimalMode anyways. Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162 Reviewed-on: https://chromium-review.googlesource.com/c/1361160 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@{#58253}
2018-12-14 19:35:34 +00:00
extern operator '.shared_function_info'
macro LoadJSFunctionSharedFunctionInfo(JSFunction): SharedFunctionInfo;
extern operator '.formal_parameter_count'
macro LoadSharedFunctionInfoFormalParameterCount(SharedFunctionInfo): int32;
[torque] add union types This adds support for union types to Torque. There is a new type expression A | B to form the union of the type expressions A and B. This is only possible if A and B have a common supertype, to prevent nonsensical unions of types with different representations. Union types are normalized: A | B == B | A A | (B | C) == (A | B) | C A | A == A The subtyping rules are defined recursively: (A | B) <: C if A <: C and B <: C A <: (B | C) if A <: B or A <: C This allows to define Object as a union type: type Tagged generates 'TNode<Object>'; type Smi extends Tagged generates 'TNode<Smi>'; type HeapObject extends Tagged generates 'TNode<HeapObject>'; type Object = Smi | HeapObject; The type {Tagged} is introduced to have a common supertype of all tagged values, but we should not use it directly, because {Object} contains the additional information that there is nothing but {Smi} and {HeapObject} values. When mapping union types to CSA types, we select the most specific common supertype. For Number and Numeric, we already use union types on the CSA side. Since it is not possible to map to CSA union types in general, we special-case these two union types to map them to the CSA union types we already use. Bug: v8:7793 Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908 Reviewed-on: https://chromium-review.googlesource.com/1076132 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53411}
2018-05-29 13:31:56 +00:00
type JSBoundFunction extends JSObject generates 'TNode<JSBoundFunction>';
Fix formatting of Torque union types Change-Id: Id5e25509cba272083caee62a1ae7420f77f3fa50 Reviewed-on: https://chromium-review.googlesource.com/c/1297949 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56937}
2018-10-24 11:28:28 +00:00
type Callable = JSFunction | JSBoundFunction | JSProxy;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type Map extends HeapObject generates 'TNode<Map>';
type FixedArrayBase extends HeapObject generates 'TNode<FixedArrayBase>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type FixedArray extends FixedArrayBase generates 'TNode<FixedArray>';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
type FixedDoubleArray extends FixedArrayBase
generates 'TNode<FixedDoubleArray>';
type FixedTypedArrayBase extends FixedArrayBase
generates 'TNode<FixedTypedArrayBase>';
type FixedTypedArray extends FixedTypedArrayBase
generates 'TNode<FixedTypedArray>';
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
type SloppyArgumentsElements extends FixedArray
generates 'TNode<FixedArray>';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
type NumberDictionary extends HeapObject
generates 'TNode<NumberDictionary>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
// RawObjectCasts should *never* be used anywhere in Torque code except for
Reland "[torque] Implement intrinsics support" This is a reland of 74a0ad7ddacc9b16233ff7d6f3d7972a4e48b149 Original change's description: > [torque] Implement intrinsics support > > Also add the first intrinsic and usage of it: %RawCast > > Bug: v8:7793 > Change-Id: Id1e3288e8bab6adb510731076a39590e8fd156be > Reviewed-on: https://chromium-review.googlesource.com/c/1344152 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57692} Bug: v8:7793 Change-Id: I315c7d44f265d0f937598e8afb1c28b08d6a23da Reviewed-on: https://chromium-review.googlesource.com/c/1347472 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57715}
2018-11-21 15:20:40 +00:00
// in Torque-based UnsafeCast operators preceeded by an appropriate
// type assert()
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
intrinsic %RawObjectCast<A: type>(o: Object): A;
intrinsic %RawPointerCast<A: type>(p: RawPtr): A;
intrinsic %RawConstexprCast<To: type, From: type>(f: From): To;
Reland "[torque] Implement intrinsics support" This is a reland of 74a0ad7ddacc9b16233ff7d6f3d7972a4e48b149 Original change's description: > [torque] Implement intrinsics support > > Also add the first intrinsic and usage of it: %RawCast > > Bug: v8:7793 > Change-Id: Id1e3288e8bab6adb510731076a39590e8fd156be > Reviewed-on: https://chromium-review.googlesource.com/c/1344152 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57692} Bug: v8:7793 Change-Id: I315c7d44f265d0f937598e8afb1c28b08d6a23da Reviewed-on: https://chromium-review.googlesource.com/c/1347472 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57715}
2018-11-21 15:20:40 +00:00
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
type NativeContextSlot generates 'TNode<IntPtrT>' constexpr 'int32_t';
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
const ARRAY_JOIN_STACK_INDEX: constexpr NativeContextSlot
generates 'Context::ARRAY_JOIN_STACK_INDEX';
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
const OBJECT_FUNCTION_INDEX: constexpr NativeContextSlot
generates 'Context::OBJECT_FUNCTION_INDEX';
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
const ITERATOR_RESULT_MAP_INDEX: constexpr NativeContextSlot
generates 'Context::ITERATOR_RESULT_MAP_INDEX';
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
extern operator '[]' macro LoadContextElement(
NativeContext, NativeContextSlot): Object;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '[]=' macro StoreContextElement(
NativeContext, NativeContextSlot, Object): void;
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
extern operator '[]' macro LoadContextElement(Context, intptr): Object;
extern operator '[]' macro LoadContextElement(Context, Smi): Object;
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type JSArrayBuffer extends JSObject generates 'TNode<JSArrayBuffer>';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
type JSArrayBufferView extends JSObject
generates 'TNode<JSArrayBufferView>';
type JSTypedArray extends JSArrayBufferView
generates 'TNode<JSTypedArray>';
[torque] Move remaining DataView getters to Torque This CL completely removes the C++ builtin implementation of the DataView.prototype.buffer, DataView.prototype.byteLength, and DataView.prototype.byteOffset getters, and moves them to a Torque implementation (that still relies on a bit of CSA). Change-Id: Id46678ae709c3787b7b93d0f78bd2a6e16e00f7b Reviewed-on: https://chromium-review.googlesource.com/1070369 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53339}
2018-05-24 13:43:57 +00:00
type JSDataView extends JSArrayBufferView generates 'TNode<JSDataView>';
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type InstanceType generates 'TNode<Int32T>' constexpr 'InstanceType';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type ElementsKind generates 'TNode<Int32T>' constexpr 'ElementsKind';
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
type LanguageMode extends Tagged
generates 'TNode<Smi>' constexpr 'LanguageMode';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
type ExtractFixedArrayFlags
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
generates 'TNode<Smi>'
constexpr 'CodeStubAssembler::ExtractFixedArrayFlags';
type ParameterMode
generates 'TNode<Int32T>' constexpr 'ParameterMode';
[cleanup] Move enum Heap::RootListIndex to enum class RootIndex 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/1234613 Reviewed-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}
2018-09-20 10:14:46 +00:00
type RootIndex generates 'TNode<Int32T>' constexpr 'RootIndex';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
type WriteBarrierMode
generates 'TNode<Int32T>' constexpr 'WriteBarrierMode';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
Move MessageTemplate enum into its own header file The primary purpose of this is to untangle a circular dependency objects.h -> handles.h -> objects.h. Most compilation units only need message-template.h, without the rest of messages.h. Bonus: change the enum to an enum class for improved type safety. Bug: v8:3770 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I8102c55197a450811de2588a68a08e7f99ea6b9e Reviewed-on: https://chromium-review.googlesource.com/c/1272193 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#56583}
2018-10-11 21:35:34 +00:00
type MessageTemplate constexpr 'MessageTemplate';
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
type ToIntegerTruncationMode
constexpr 'CodeStubAssembler::ToIntegerTruncationMode';
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
type AllocationFlags constexpr 'AllocationFlags';
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
const kSmiTagSize: constexpr int31 generates 'kSmiTagSize';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const NO_ELEMENTS: constexpr ElementsKind generates 'NO_ELEMENTS';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const PACKED_SMI_ELEMENTS:
constexpr ElementsKind generates 'PACKED_SMI_ELEMENTS';
const HOLEY_SMI_ELEMENTS:
constexpr ElementsKind generates 'HOLEY_SMI_ELEMENTS';
[torque]: Require formatting for .tq files in presubmit Bug: v8:7793 Change-Id: I18bd30b36be3c3f89962a2e9c04d8f159c8cfe2b Reviewed-on: https://chromium-review.googlesource.com/1240415 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56202}
2018-09-25 10:59:03 +00:00
const PACKED_ELEMENTS:
constexpr ElementsKind generates 'PACKED_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const HOLEY_ELEMENTS: constexpr ElementsKind generates 'HOLEY_ELEMENTS';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const PACKED_DOUBLE_ELEMENTS:
constexpr ElementsKind generates 'PACKED_DOUBLE_ELEMENTS';
const HOLEY_DOUBLE_ELEMENTS:
constexpr ElementsKind generates 'HOLEY_DOUBLE_ELEMENTS';
const DICTIONARY_ELEMENTS:
constexpr ElementsKind generates 'DICTIONARY_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const UINT8_ELEMENTS: constexpr ElementsKind generates 'UINT8_ELEMENTS';
const INT8_ELEMENTS: constexpr ElementsKind generates 'INT8_ELEMENTS';
[torque]: Require formatting for .tq files in presubmit Bug: v8:7793 Change-Id: I18bd30b36be3c3f89962a2e9c04d8f159c8cfe2b Reviewed-on: https://chromium-review.googlesource.com/1240415 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56202}
2018-09-25 10:59:03 +00:00
const UINT16_ELEMENTS:
constexpr ElementsKind generates 'UINT16_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const INT16_ELEMENTS: constexpr ElementsKind generates 'INT16_ELEMENTS';
[torque]: Require formatting for .tq files in presubmit Bug: v8:7793 Change-Id: I18bd30b36be3c3f89962a2e9c04d8f159c8cfe2b Reviewed-on: https://chromium-review.googlesource.com/1240415 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56202}
2018-09-25 10:59:03 +00:00
const UINT32_ELEMENTS:
constexpr ElementsKind generates 'UINT32_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const INT32_ELEMENTS: constexpr ElementsKind generates 'INT32_ELEMENTS';
[torque]: Require formatting for .tq files in presubmit Bug: v8:7793 Change-Id: I18bd30b36be3c3f89962a2e9c04d8f159c8cfe2b Reviewed-on: https://chromium-review.googlesource.com/1240415 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56202}
2018-09-25 10:59:03 +00:00
const FLOAT32_ELEMENTS:
constexpr ElementsKind generates 'FLOAT32_ELEMENTS';
const FLOAT64_ELEMENTS:
constexpr ElementsKind generates 'FLOAT64_ELEMENTS';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const UINT8_CLAMPED_ELEMENTS:
constexpr ElementsKind generates 'UINT8_CLAMPED_ELEMENTS';
const BIGUINT64_ELEMENTS:
constexpr ElementsKind generates 'BIGUINT64_ELEMENTS';
const BIGINT64_ELEMENTS:
constexpr ElementsKind generates 'BIGINT64_ELEMENTS';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
const kNone:
constexpr AllocationFlags generates 'CodeStubAssembler::kNone';
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
const kDoubleAlignment:
constexpr AllocationFlags generates 'kDoubleAlignment';
const kPretenured: constexpr AllocationFlags generates 'kPretenured';
const kAllowLargeObjectAllocation:
constexpr AllocationFlags generates 'kAllowLargeObjectAllocation';
[typedarray] Change TypedArray.p.sort implementation. This CL uses the new function pointers and generic features of Torque to improve the performance of TypedArray.p.sort. Instead of one Load/Store builtin that dispatches at runtime based on the element kind, there are now many small builtins (one for each element kind). The sorting algorithm then uses function pointers to those small builtins, which get set once. Changes in the relevant benchmarks: Benchmark Original (JS) Current This CL IntTypes 83.9 202.3 240.7 BigIntTypes 32.1 47.2 53.3 FloatTypes 99.3 109.3 129.3 Bug: v8:7382 Change-Id: I8684410524d546615b19f6edcbfdc615068196aa Reviewed-on: https://chromium-review.googlesource.com/1070069 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53322}
2018-05-24 09:25:58 +00:00
type FixedUint8Array extends FixedTypedArray;
type FixedInt8Array extends FixedTypedArray;
type FixedUint16Array extends FixedTypedArray;
type FixedInt16Array extends FixedTypedArray;
type FixedUint32Array extends FixedTypedArray;
type FixedInt32Array extends FixedTypedArray;
type FixedFloat32Array extends FixedTypedArray;
type FixedFloat64Array extends FixedTypedArray;
type FixedUint8ClampedArray extends FixedTypedArray;
type FixedBigUint64Array extends FixedTypedArray;
type FixedBigInt64Array extends FixedTypedArray;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kFixedDoubleArrays: constexpr ExtractFixedArrayFlags
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
generates 'CodeStubAssembler::ExtractFixedArrayFlag::kFixedDoubleArrays';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kAllFixedArrays: constexpr ExtractFixedArrayFlags
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
generates 'CodeStubAssembler::ExtractFixedArrayFlag::kAllFixedArrays';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kFixedArrays: constexpr ExtractFixedArrayFlags
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
generates 'CodeStubAssembler::ExtractFixedArrayFlag::kFixedArrays';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kFixedCOWArrayMapRootIndex:
constexpr RootIndex generates 'RootIndex::kFixedCOWArrayMap';
const kEmptyFixedArrayRootIndex:
constexpr RootIndex generates 'RootIndex::kEmptyFixedArray';
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
const kTheHoleValueRootIndex:
constexpr RootIndex generates 'RootIndex::kTheHoleValue';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kInvalidArrayLength: constexpr MessageTemplate
generates 'MessageTemplate::kInvalidArrayLength';
const kCalledNonCallable: constexpr MessageTemplate
generates 'MessageTemplate::kCalledNonCallable';
const kCalledOnNullOrUndefined: constexpr MessageTemplate
generates 'MessageTemplate::kCalledOnNullOrUndefined';
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
const kIteratorValueNotAnObject: constexpr MessageTemplate
generates 'MessageTemplate::kIteratorValueNotAnObject';
const kNotIterable: constexpr MessageTemplate
generates 'MessageTemplate::kNotIterable';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
[builtin] Array.p.join throws on invalid Array lengths. This matches the pre-torque behavior when the receiver's length was greater than the max array length. Bug: chromium:902672 Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203 Reviewed-on: https://chromium-review.googlesource.com/c/1330921 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57456}
2018-11-13 08:58:09 +00:00
const kMaxArrayIndex:
constexpr uint32 generates 'JSArray::kMaxArrayIndex';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const kMaxSafeInteger: constexpr float64 generates 'kMaxSafeInteger';
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
const kStringMaxLength: constexpr int31 generates 'String::kMaxLength';
const kFixedArrayMaxLength:
constexpr int31 generates 'FixedArray::kMaxLength';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
const kMaxRegularHeapObjectSize: constexpr int31
generates 'kMaxRegularHeapObjectSize';
const kMaxNewSpaceFixedArrayElements: constexpr int31
generates 'FixedArray::kMaxRegularLength';
const kSloppyArgumentsArgumentsIndex: constexpr int31
generates 'SloppyArgumentsElements::kArgumentsIndex';
const kSloppyArgumentsContextIndex: constexpr int31
generates 'SloppyArgumentsElements::kContextIndex';
const kSloppyArgumentsParameterMapStart: constexpr int31
generates 'SloppyArgumentsElements::kParameterMapStart';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kTruncateMinusZero: constexpr ToIntegerTruncationMode
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
generates 'CodeStubAssembler::ToIntegerTruncationMode::kTruncateMinusZero'
;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
[torque]: Require formatting for .tq files in presubmit Bug: v8:7793 Change-Id: I18bd30b36be3c3f89962a2e9c04d8f159c8cfe2b Reviewed-on: https://chromium-review.googlesource.com/1240415 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56202}
2018-09-25 10:59:03 +00:00
const kNotTypedArray: constexpr MessageTemplate
generates 'MessageTemplate::kNotTypedArray';
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const kDetachedOperation: constexpr MessageTemplate
generates 'MessageTemplate::kDetachedOperation';
const kBadSortComparisonFunction: constexpr MessageTemplate
generates 'MessageTemplate::kBadSortComparisonFunction';
const kIncompatibleMethodReceiver: constexpr MessageTemplate
generates 'MessageTemplate::kIncompatibleMethodReceiver';
const kInvalidDataViewAccessorOffset: constexpr MessageTemplate
generates 'MessageTemplate::kInvalidDataViewAccessorOffset';
const kStrictReadOnlyProperty: constexpr MessageTemplate
generates 'MessageTemplate::kStrictReadOnlyProperty';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
Incremental Torque type cleanup Includes creating Oddball-specific types. Change-Id: Ib5d80dfe95838b2deb0a2fcae67c349940970252 Reviewed-on: https://chromium-review.googlesource.com/c/1342930 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57655}
2018-11-20 13:18:31 +00:00
type Hole extends Oddball generates 'TNode<Oddball>';
type Null extends Oddball generates 'TNode<Oddball>';
type Undefined extends Oddball generates 'TNode<Oddball>';
type True extends Oddball generates 'TNode<Oddball>';
type False extends Oddball generates 'TNode<Oddball>';
type Boolean = True | False;
type NumberOrUndefined = Number | Undefined;
extern macro TheHoleConstant(): Hole;
extern macro NullConstant(): Null;
extern macro UndefinedConstant(): Undefined;
extern macro TrueConstant(): True;
extern macro FalseConstant(): False;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern macro Int32TrueConstant(): bool;
extern macro Int32FalseConstant(): bool;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro EmptyStringConstant(): String;
Introduce 'kLengthString' in torque code This CL replaces occurrences of "length" with the CSA macro LengthStringConstant(). R=jgruber@chromium.org Bug: v8:8015 Change-Id: Idf095587940f859e4c634865560abae325cd9fb4 Reviewed-on: https://chromium-review.googlesource.com/1201782 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55578}
2018-09-03 05:40:21 +00:00
extern macro LengthStringConstant(): String;
[torque][clenaup] Rename Constant to ExternConstant This CL renames Constant to ExternConstant (this already happend in the grammar). It also enforces the rule that such extern constants require "constexpr" types. Drive-by-change: Replaced non constexpr extern constants with module constants. R=tebbi@chromium.org Bug: v8:7793 Change-Id: Icb3f75071b15b1fcabbe447941e05dd5a09d4b23 Reviewed-on: https://chromium-review.googlesource.com/1136434 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#54453}
2018-07-13 11:09:17 +00:00
Incremental Torque type cleanup Includes creating Oddball-specific types. Change-Id: Ib5d80dfe95838b2deb0a2fcae67c349940970252 Reviewed-on: https://chromium-review.googlesource.com/c/1342930 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#57655}
2018-11-20 13:18:31 +00:00
const Hole: Hole = TheHoleConstant();
const Null: Null = NullConstant();
const Undefined: Undefined = UndefinedConstant();
const True: True = TrueConstant();
const False: False = FalseConstant();
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
const kEmptyString: String = EmptyStringConstant();
Introduce 'kLengthString' in torque code This CL replaces occurrences of "length" with the CSA macro LengthStringConstant(). R=jgruber@chromium.org Bug: v8:8015 Change-Id: Idf095587940f859e4c634865560abae325cd9fb4 Reviewed-on: https://chromium-review.googlesource.com/1201782 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55578}
2018-09-03 05:40:21 +00:00
const kLengthString: String = LengthStringConstant();
[torque][clenaup] Rename Constant to ExternConstant This CL renames Constant to ExternConstant (this already happend in the grammar). It also enforces the rule that such extern constants require "constexpr" types. Drive-by-change: Replaced non constexpr extern constants with module constants. R=tebbi@chromium.org Bug: v8:7793 Change-Id: Icb3f75071b15b1fcabbe447941e05dd5a09d4b23 Reviewed-on: https://chromium-review.googlesource.com/1136434 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#54453}
2018-07-13 11:09:17 +00:00
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const true: constexpr bool generates 'true';
const false: constexpr bool generates 'false';
const kStrict: constexpr LanguageMode generates 'LanguageMode::kStrict';
const kSloppy: constexpr LanguageMode generates 'LanguageMode::kSloppy';
[torque] enable multiple inheritance from Torque-generated assemblers 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/1341955 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
const SMI_PARAMETERS: constexpr ParameterMode
generates 'CodeStubAssembler::SMI_PARAMETERS';
const INTPTR_PARAMETERS: constexpr ParameterMode
generates 'CodeStubAssembler::INTPTR_PARAMETERS';
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
const SKIP_WRITE_BARRIER:
constexpr WriteBarrierMode generates 'SKIP_WRITE_BARRIER';
[array] Skip write barrier when sorting packed Smis R=jgruber@chromium.org Bug: chromium:873555 Change-Id: I6268bedf47a89194875d1179e603bcfe972c9d68 Reviewed-on: https://chromium-review.googlesource.com/1172282 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55077}
2018-08-13 08:43:56 +00:00
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Is64(): constexpr bool;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern macro SelectBooleanConstant(bool): Boolean;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro Print(constexpr string);
extern macro Print(constexpr string, Object);
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro Comment(constexpr string);
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro Print(Object);
extern macro DebugBreak();
extern macro ToInteger_Inline(Context, Object): Number;
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
extern macro ToInteger_Inline(
Context, Object, constexpr ToIntegerTruncationMode): Number;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro ToLength_Inline(Context, Object): Number;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
extern macro ToNumber_Inline(Context, Object): Number;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro ToString_Inline(Context, Object): String;
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning macro GetProperty(implicit context: Context)(
Object, Object): Object;
extern transitioning builtin SetProperty(implicit context: Context)(
Object, Object, Object);
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
extern transitioning builtin SetPropertyInLiteral(implicit context: Context)(
Object, Object, Object);
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning builtin DeleteProperty(implicit context: Context)(
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
Object, Object, LanguageMode);
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning builtin HasProperty(implicit context: Context)(
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
JSReceiver, Object): Boolean;
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning macro HasProperty_Inline(implicit context: Context)(
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
JSReceiver, Object): Boolean;
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
extern macro ThrowRangeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate, Object): never;
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
extern macro ThrowTypeError(
Context, constexpr MessageTemplate, Object, Object, Object): never;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro ArraySpeciesCreate(Context, Object, Number): JSReceiver;
Port Array.of to Torque 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/1296464 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
2018-10-24 09:31:21 +00:00
extern macro ArrayCreate(implicit context: Context)(Number): JSArray;
[Torque] Array.prototype.filter moves to Torque. 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}
2019-01-08 14:49:43 +00:00
extern macro BuildAppendJSArray(
constexpr ElementsKind, FastJSArray, Object): void labels Bailout;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro EnsureArrayPushable(Map): ElementsKind
labels Bailout;
[array] Move Array.p.unshift fall-back to Torque This CL implements a generic baseline version of Array.p.unshift in Torque, enabling us to remove the JS fall-back. The elements-accessor fast-path is still used, but the check whether to use it is also moved to Torque. Support for sparse JSArrays is removed. Drive-by change: Small refactoring in builtins-array that will get extended to other array builtins in a follow-up CL. R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7624 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7b23ce15e7b922eb333f61a408050dedec77c95a Reviewed-on: https://chromium-review.googlesource.com/1189902 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55670}
2018-09-06 05:47:23 +00:00
extern macro EnsureArrayLengthWritable(Map) labels Bailout;
Port Array.of to Torque 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/1296464 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
2018-10-24 09:31:21 +00:00
// TODO: Reduce duplication once varargs are supported in macros.
extern macro Construct(implicit context: Context)(
Constructor, Object): JSReceiver;
extern macro Construct(implicit context: Context)(
Constructor, Object, Object): JSReceiver;
extern macro Construct(implicit context: Context)(
Constructor, Object, Object, Object): JSReceiver;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
Reland "[array] Use random middle element to determine pivot during sorting" This is a reland of 91bab5588c60497e200fa89a846e136b695db510 This CL contains two major changes w.r.t to the original CL: The random state is removed from the Smi root list and we pre-seed the RNG on each sort with the length of the array. To cut down on the length of the arguments list and to keep track of the random state across recursive calls, we move most of the sort arguments into a FixedArray and reload from the array for each recursion. Original change's description: > [array] Use random middle element to determine pivot during sorting > > This CL adds a "random state" to the Smi Root list and implements a > basic Linear congruential pseudo random number generator in Torque. > > The RNG is used to determine the pivot element for sorting. This will > prevent the worst cases for certain data layouts. > > Drive-by-fix: Make sorting of ranges and execution pauses for profviz > deterministic by adding a secondary sorting criteria. > > Bug: v8:7382 > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ieb871e98e74bdb803f821b0cd35d2f67ee0f2868 > Reviewed-on: https://chromium-review.googlesource.com/1082193 > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Simon Zünd <szuend@google.com> > Cr-Commit-Position: refs/heads/master@{#53524} Bug: v8:7382 Change-Id: Ia7bef7ed1c0e904ffe43bc428e702f64f9c6a60b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1087888 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53583}
2018-06-07 11:48:26 +00:00
extern builtin ToObject(Context, Object): JSReceiver;
[csa] Add ToObject_Inline macro This CL adds a ToObject_Inline CSA macro that avoids the "ToObject" builtin call if the passed argument is already a JSReceiver. The CL also replaces all occurences of ToObject in Torque code with ToObject_Inline. R=jgruber@chromium.org Change-Id: I1cd66d5d51dde5a93d9a0c55489b13a6f4ba9dc2 Reviewed-on: https://chromium-review.googlesource.com/1169819 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55039}
2018-08-10 08:35:23 +00:00
extern macro ToObject_Inline(Context, Object): JSReceiver;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro IsNullOrUndefined(Object): bool;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
extern macro IsTheHole(Object): bool;
extern macro IsString(HeapObject): bool;
extern builtin ToString(Context, Object): String;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning runtime NormalizeElements(Context, JSObject);
extern transitioning runtime TransitionElementsKindWithKind(
Context, JSObject, Smi);
extern transitioning runtime CreateDataProperty(implicit context: Context)(
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
JSReceiver, Object, Object);
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern macro LoadBufferObject(RawPtr, constexpr int32): Object;
extern macro LoadBufferPointer(RawPtr, constexpr int32): RawPtr;
extern macro LoadBufferSmi(RawPtr, constexpr int32): Smi;
[cleanup] Move enum Heap::RootListIndex to enum class RootIndex 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/1234613 Reviewed-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}
2018-09-20 10:14:46 +00:00
extern macro LoadRoot(constexpr RootIndex): Object;
extern macro StoreRoot(constexpr RootIndex, Object): Object;
extern macro LoadAndUntagToWord32Root(constexpr RootIndex): int32;
Reland "[array] Use random middle element to determine pivot during sorting" This is a reland of 91bab5588c60497e200fa89a846e136b695db510 This CL contains two major changes w.r.t to the original CL: The random state is removed from the Smi root list and we pre-seed the RNG on each sort with the length of the array. To cut down on the length of the arguments list and to keep track of the random state across recursive calls, we move most of the sort arguments into a FixedArray and reload from the array for each recursion. Original change's description: > [array] Use random middle element to determine pivot during sorting > > This CL adds a "random state" to the Smi Root list and implements a > basic Linear congruential pseudo random number generator in Torque. > > The RNG is used to determine the pivot element for sorting. This will > prevent the worst cases for certain data layouts. > > Drive-by-fix: Make sorting of ranges and execution pauses for profviz > deterministic by adding a secondary sorting criteria. > > Bug: v8:7382 > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ieb871e98e74bdb803f821b0cd35d2f67ee0f2868 > Reviewed-on: https://chromium-review.googlesource.com/1082193 > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Simon Zünd <szuend@google.com> > Cr-Commit-Position: refs/heads/master@{#53524} Bug: v8:7382 Change-Id: Ia7bef7ed1c0e904ffe43bc428e702f64f9c6a60b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1087888 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53583}
2018-06-07 11:48:26 +00:00
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern runtime StringEqual(Context, String, String): Oddball;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
extern builtin StringLessThan(Context, String, String): Boolean;
extern macro StrictEqual(Object, Object): Boolean;
[array] Use CallCFunction3 for SmiLexicographicCompare This CL changes the call-site of SmiLexicographicCompare to a fast c call instead of a runtime call. The runtime function is not deleted as it is still used in InnerArraySort. The test is also moved from mjsunit to cctest, to make removal of the runtime function easier in the future. R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: Ie961eeb094c13018e9ec28b68f7c444d7f889036 Reviewed-on: https://chromium-review.googlesource.com/1201587 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@{#55642}
2018-09-05 09:28:55 +00:00
extern macro SmiLexicographicCompare(Smi, Smi): Smi;
[torque] allow return type never for runtime functions Motivated by https://crrev.com/c/1196693, this allows to declare runtime functions with return type never in Torque. For example: extern runtime ReThrow(Context, Object) : never; Change-Id: I5dd8fe0ca22c778364bfcf1caf52180039c5be7e Reviewed-on: https://chromium-review.googlesource.com/c/1282957 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56709}
2018-10-16 21:14:05 +00:00
extern runtime ReThrow(Context, Object): never;
[builtins] Change A.p.join invalid string length errors to use ThrowInvalidStringLength runtime. This is to enable switching from throwing a JS exception (RangeError) to an abort when the --abort_on_stack_or_string_length_overflow flag is set. Bug: chromium:901652 Change-Id: Ia3ff2ec55e77a4f60d715f0bc767e6180a5e001a Reviewed-on: https://chromium-review.googlesource.com/c/1322312 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#57307}
2018-11-07 07:28:15 +00:00
extern runtime ThrowInvalidStringLength(Context): never;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern operator '==' macro WordEqual(RawPtr, RawPtr): bool;
extern operator '!=' macro WordNotEqual(RawPtr, RawPtr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '<' macro Int32LessThan(int32, int32): bool;
Fix BigInt builtins and TurboFan support after BigInt header layout change broken by: [cleanup] Fix kPointerSize usages in src/objects/bigint.* Bug: v8:8477, v8:8238 Change-Id: If1961ae42e1969d4ee807ea052a9c4cf4f072d0f Reviewed-on: https://chromium-review.googlesource.com/c/1357046 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57997}
2018-12-03 15:56:57 +00:00
extern operator '<' macro Uint32LessThan(uint32, uint32): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '>' macro Int32GreaterThan(int32, int32): bool;
Fix BigInt builtins and TurboFan support after BigInt header layout change broken by: [cleanup] Fix kPointerSize usages in src/objects/bigint.* Bug: v8:8477, v8:8238 Change-Id: If1961ae42e1969d4ee807ea052a9c4cf4f072d0f Reviewed-on: https://chromium-review.googlesource.com/c/1357046 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57997}
2018-12-03 15:56:57 +00:00
extern operator '>' macro Uint32GreaterThan(uint32, uint32): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '<=' macro Int32LessThanOrEqual(int32, int32): bool;
Fix BigInt builtins and TurboFan support after BigInt header layout change broken by: [cleanup] Fix kPointerSize usages in src/objects/bigint.* Bug: v8:8477, v8:8238 Change-Id: If1961ae42e1969d4ee807ea052a9c4cf4f072d0f Reviewed-on: https://chromium-review.googlesource.com/c/1357046 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57997}
2018-12-03 15:56:57 +00:00
extern operator '<=' macro Uint32LessThanOrEqual(uint32, uint32): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '>=' macro Int32GreaterThanOrEqual(int32, int32): bool;
Fix BigInt builtins and TurboFan support after BigInt header layout change broken by: [cleanup] Fix kPointerSize usages in src/objects/bigint.* Bug: v8:8477, v8:8238 Change-Id: If1961ae42e1969d4ee807ea052a9c4cf4f072d0f Reviewed-on: https://chromium-review.googlesource.com/c/1357046 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57997}
2018-12-03 15:56:57 +00:00
extern operator '>=' macro Uint32GreaterThanOrEqual(uint32, uint32): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro SmiEqual(Smi, Smi): bool;
extern operator '!=' macro SmiNotEqual(Smi, Smi): bool;
extern operator '<' macro SmiLessThan(Smi, Smi): bool;
extern operator '<=' macro SmiLessThanOrEqual(Smi, Smi): bool;
extern operator '>' macro SmiGreaterThan(Smi, Smi): bool;
extern operator '>=' macro SmiGreaterThanOrEqual(Smi, Smi): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
extern operator '==' macro ElementsKindEqual(
constexpr ElementsKind, constexpr ElementsKind): constexpr bool;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern operator '==' macro ElementsKindEqual(ElementsKind, ElementsKind): bool;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
operator '!=' macro ElementsKindNotEqual(
k1: ElementsKind, k2: ElementsKind): bool {
return !ElementsKindEqual(k1, k2);
}
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro IsElementsKindLessThanOrEqual(
ElementsKind, constexpr ElementsKind): bool;
extern macro IsElementsKindGreaterThan(
ElementsKind, constexpr ElementsKind): bool;
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
extern macro IsFastElementsKind(constexpr ElementsKind): constexpr bool;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro IsDoubleElementsKind(constexpr ElementsKind): constexpr bool;
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
extern macro IsFastAliasedArgumentsMap(implicit context: Context)(Map): bool;
extern macro IsSlowAliasedArgumentsMap(implicit context: Context)(Map): bool;
extern macro IsSloppyArgumentsMap(implicit context: Context)(Map): bool;
extern macro IsStrictArgumentsMap(implicit context: Context)(Map): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro SmiAbove(Smi, Smi): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro WordEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '==' macro WordEqual(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '!=' macro WordNotEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '!=' macro WordNotEqual(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '<' macro IntPtrLessThan(intptr, intptr): bool;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '<' macro UintPtrLessThan(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '>' macro IntPtrGreaterThan(intptr, intptr): bool;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '>' macro UintPtrGreaterThan(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '<=' macro IntPtrLessThanOrEqual(intptr, intptr): bool;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '<=' macro UintPtrLessThanOrEqual(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '>=' macro IntPtrGreaterThanOrEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '>=' macro UintPtrGreaterThanOrEqual(uintptr, uintptr): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro Float64Equal(float64, float64): bool;
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
extern operator '!=' macro Float64NotEqual(float64, float64): bool;
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
extern operator '>' macro Float64GreaterThan(float64, float64): bool;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '==' macro BranchIfNumberEqual(Number, Number): never
labels Taken, NotTaken;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '!=' macro BranchIfNumberNotEqual(Number, Number): never
labels Taken, NotTaken;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '<' macro BranchIfNumberLessThan(Number, Number): never
labels Taken, NotTaken;
extern operator '<=' macro BranchIfNumberLessThanOrEqual(Number, Number): never
labels Taken, NotTaken;
extern operator '>' macro BranchIfNumberGreaterThan(Number, Number): never
labels Taken, NotTaken;
[Torque] Rename modules to namespaces BUG=v8:7793 Change-Id: Ibcf16998ef9a44ae899a2536ccf02af1b7b7193d Reviewed-on: https://chromium-review.googlesource.com/c/1333410 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57469}
2018-11-13 13:00:34 +00:00
extern operator '>=' macro BranchIfNumberGreaterThanOrEqual(
Number, Number): never
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels Taken, NotTaken;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro WordEqual(Object, Object): bool;
extern operator '!=' macro WordNotEqual(Object, Object): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '+' macro SmiAdd(Smi, Smi): Smi;
extern operator '-' macro SmiSub(Smi, Smi): Smi;
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
extern operator '&' macro SmiAnd(Smi, Smi): Smi;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern operator '|' macro SmiOr(Smi, Smi): Smi;
extern operator '<<' macro SmiShl(Smi, constexpr int31): Smi;
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern operator '>>' macro SmiSar(Smi, constexpr int31): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '+' macro IntPtrAdd(intptr, intptr): intptr;
extern operator '-' macro IntPtrSub(intptr, intptr): intptr;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '*' macro IntPtrMul(intptr, intptr): intptr;
[builtins] Fix Array.p.join overflow detection Additionally, introduce IntPtrDiv to CodeAssembler. Change-Id: I9396f77b90a2fadb0179028d44475e616be3d081 Reviewed-on: https://chromium-review.googlesource.com/c/1285400 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56776}
2018-10-18 12:53:22 +00:00
extern operator '/' macro IntPtrDiv(intptr, intptr): intptr;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern operator '<<' macro WordShl(intptr, intptr): intptr;
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern operator '>>' macro WordSar(intptr, intptr): intptr;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern operator '&' macro WordAnd(intptr, intptr): intptr;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '|' macro WordOr(intptr, intptr): intptr;
extern operator '+' macro UintPtrAdd(uintptr, uintptr): uintptr;
extern operator '-' macro UintPtrSub(uintptr, uintptr): uintptr;
extern operator '>>>' macro WordShr(uintptr, uintptr): uintptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '&' macro WordAnd(uintptr, uintptr): uintptr;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '|' macro WordOr(uintptr, uintptr): uintptr;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
extern operator '+' macro Int32Add(int32, int32): int32;
[builtin] Array.p.join throws on invalid Array lengths. This matches the pre-torque behavior when the receiver's length was greater than the max array length. Bug: chromium:902672 Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203 Reviewed-on: https://chromium-review.googlesource.com/c/1330921 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57456}
2018-11-13 08:58:09 +00:00
extern operator '+' macro ConstexprUint32Add(
constexpr uint32, constexpr int32): constexpr uint32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern operator '-' macro Int32Sub(int32, int32): int32;
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
extern operator '*' macro Int32Mul(int32, int32): int32;
extern operator '%' macro Int32Mod(int32, int32): int32;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '&' macro Word32And(int32, int32): int32;
extern operator '&' macro Word32And(uint32, uint32): uint32;
[torque] Add constexpr int31 equality operator This CL adds a constexpr int31 == operator that returns a constexpr bool value. It also fixes a bug that this introduces because branch generation for ternary operators incorrectly assumed that the condition value was bool, whereas it can also be constexpr bool now. Change-Id: Ie7d3497c9d1112c121b4a29561fe065b5bf01fb6 Reviewed-on: https://chromium-review.googlesource.com/1106343 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53867}
2018-06-19 15:58:56 +00:00
extern operator '==' macro
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
ConstexprInt31Equal(constexpr int31, constexpr int31): constexpr bool;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '==' macro Word32Equal(int32, int32): bool;
extern operator '==' macro Word32Equal(uint32, uint32): bool;
extern operator '!=' macro Word32NotEqual(int32, int32): bool;
extern operator '!=' macro Word32NotEqual(uint32, uint32): bool;
extern operator '>>>' macro Word32Shr(uint32, uint32): uint32;
extern operator '<<' macro Word32Shl(int32, int32): int32;
extern operator '<<' macro Word32Shl(uint32, uint32): uint32;
extern operator '|' macro Word32Or(int32, int32): int32;
extern operator '|' macro Word32Or(uint32, uint32): uint32;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '&' macro Word32And(bool, bool): bool;
extern operator '|' macro Word32Or(bool, bool): bool;
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
extern operator '+' macro Float64Add(float64, float64): float64;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '+' macro NumberAdd(Number, Number): Number;
extern operator '-' macro NumberSub(Number, Number): Number;
[torque] a new self-contained parser for torque Bug: v8:7793 Change-Id: I208edf856f0283d840358f3c11bab97af0397056 Reviewed-on: https://chromium-review.googlesource.com/1095192 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54574}
2018-07-18 18:03:45 +00:00
extern macro NumberMin(Number, Number): Number;
extern macro NumberMax(Number, Number): Number;
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
macro Min(x: Number, y: Number): Number {
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
return NumberMin(x, y);
[torque] a new self-contained parser for torque Bug: v8:7793 Change-Id: I208edf856f0283d840358f3c11bab97af0397056 Reviewed-on: https://chromium-review.googlesource.com/1095192 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54574}
2018-07-18 18:03:45 +00:00
}
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
macro Max(x: Number, y: Number): Number {
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
return NumberMax(x, y);
[torque] a new self-contained parser for torque Bug: v8:7793 Change-Id: I208edf856f0283d840358f3c11bab97af0397056 Reviewed-on: https://chromium-review.googlesource.com/1095192 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54574}
2018-07-18 18:03:45 +00:00
}
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern operator '<<' macro ConstexprUintPtrShl(
constexpr uintptr, constexpr int31): constexpr uintptr;
extern operator '>>>' macro ConstexprUintPtrShr(
constexpr uintptr, constexpr int31): constexpr uintptr;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern macro SmiMax(Smi, Smi): Smi;
extern macro SmiMin(Smi, Smi): Smi;
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
extern operator '!' macro ConstexprBoolNot(constexpr bool): constexpr bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '!' macro Word32BinaryNot(bool): bool;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern operator '!' macro IsFalse(Boolean): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern operator '.map' macro LoadMap(HeapObject): Map;
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning operator '.map=' macro StoreMap(HeapObject, Map);
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '.instanceType' macro LoadInstanceType(HeapObject):
InstanceType;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '.length' macro LoadStringLengthAsWord(String): intptr;
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
extern operator '.length' macro GetArgumentsLength(constexpr Arguments): intptr;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '[]' macro GetArgumentValue(
constexpr Arguments, intptr): Object;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro TaggedIsSmi(Object): bool;
extern macro TaggedIsNotSmi(Object): bool;
Reland "[array] Use random middle element to determine pivot during sorting" This is a reland of 91bab5588c60497e200fa89a846e136b695db510 This CL contains two major changes w.r.t to the original CL: The random state is removed from the Smi root list and we pre-seed the RNG on each sort with the length of the array. To cut down on the length of the arguments list and to keep track of the random state across recursive calls, we move most of the sort arguments into a FixedArray and reload from the array for each recursion. Original change's description: > [array] Use random middle element to determine pivot during sorting > > This CL adds a "random state" to the Smi Root list and implements a > basic Linear congruential pseudo random number generator in Torque. > > The RNG is used to determine the pivot element for sorting. This will > prevent the worst cases for certain data layouts. > > Drive-by-fix: Make sorting of ranges and execution pauses for profviz > deterministic by adding a secondary sorting criteria. > > Bug: v8:7382 > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ieb871e98e74bdb803f821b0cd35d2f67ee0f2868 > Reviewed-on: https://chromium-review.googlesource.com/1082193 > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Simon Zünd <szuend@google.com> > Cr-Commit-Position: refs/heads/master@{#53524} Bug: v8:7382 Change-Id: Ia7bef7ed1c0e904ffe43bc428e702f64f9c6a60b Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1087888 Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53583}
2018-06-07 11:48:26 +00:00
extern macro TaggedIsPositiveSmi(Object): bool;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro IsValidPositiveSmi(intptr): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro HeapObjectToJSDataView(HeapObject): JSDataView
labels CastError;
[builtins] Port TypedArray join, toString, and toLocaleString to Torque. Micro-benchmarks show speed improvements across the various types: TypedArrays-JoinBigIntTypes 7246 8297 14.50% TypedArrays-JoinBigIntTypes 7194 8637 20.06% TypedArrays-JoinBigIntTypes 7258 8586 18.30% TypedArrays-JoinFloatTypes 24461 28628 17.04% TypedArrays-JoinFloatTypes 24523 29647 20.89% TypedArrays-JoinFloatTypes 24419 29327 20.10% TypedArrays-JoinIntTypes 23378 33928 45.13% TypedArrays-JoinIntTypes 23333 34034 45.86% TypedArrays-JoinIntTypes 21653 34000 57.02% TypedArrays-JoinWithSeparatorBigIntTypes 6620 7339 10.86% TypedArrays-JoinWithSeparatorBigIntTypes 6566 7579 15.43% TypedArrays-JoinWithSeparatorBigIntTypes 6631 7481 12.82% TypedArrays-JoinWithSeparatorFloatTypes 18695 19670 5.22% TypedArrays-JoinWithSeparatorFloatTypes 18518 20088 8.48% TypedArrays-JoinWithSeparatorFloatTypes 18482 20193 9.26% TypedArrays-JoinWithSeparatorIntTypes 17849 21482 20.35% TypedArrays-JoinWithSeparatorIntTypes 17831 21578 21.01% TypedArrays-JoinWithSeparatorIntTypes 17937 21578 20.30% Drive-by: Removed unused CSA helper InternalArrayCreate. Bug: v8:7624 Change-Id: I8e63815982439cfd2267417d03cd2b71b4b7a812 Reviewed-on: https://chromium-review.googlesource.com/c/1369330 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58167}
2018-12-11 15:27:31 +00:00
extern macro HeapObjectToJSTypedArray(HeapObject): JSTypedArray
labels CastError;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro TaggedToHeapObject(Object): HeapObject
labels CastError;
extern macro TaggedToSmi(Object): Smi
labels CastError;
extern macro HeapObjectToJSArray(HeapObject): JSArray
labels CastError;
extern macro HeapObjectToCallable(HeapObject): Callable
labels CastError;
extern macro HeapObjectToFixedArray(HeapObject): FixedArray
labels CastError;
extern macro HeapObjectToFixedDoubleArray(HeapObject): FixedDoubleArray
labels CastError;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro HeapObjectToString(HeapObject): String
labels CastError;
Port Array.of to Torque 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/1296464 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
2018-10-24 09:31:21 +00:00
extern macro HeapObjectToConstructor(HeapObject): Constructor
labels CastError;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro HeapObjectToHeapNumber(HeapObject): HeapNumber
labels CastError;
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
extern macro HeapObjectToSloppyArgumentsElements(HeapObject):
SloppyArgumentsElements
labels CastError;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro TaggedToNumber(Object): Number
labels CastError;
macro CastHeapObject<A: type>(o: HeapObject): A
labels CastError;
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<HeapObject>(o: HeapObject): HeapObject
labels CastError {
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
return o;
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<FixedArray>(o: HeapObject): FixedArray
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return HeapObjectToFixedArray(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<FixedDoubleArray>(o: HeapObject): FixedDoubleArray
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return HeapObjectToFixedDoubleArray(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
CastHeapObject<SloppyArgumentsElements>(o: HeapObject): SloppyArgumentsElements
labels CastError {
return HeapObjectToSloppyArgumentsElements(o) otherwise CastError;
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<JSDataView>(o: HeapObject): JSDataView
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return HeapObjectToJSDataView(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[builtins] Port TypedArray join, toString, and toLocaleString to Torque. Micro-benchmarks show speed improvements across the various types: TypedArrays-JoinBigIntTypes 7246 8297 14.50% TypedArrays-JoinBigIntTypes 7194 8637 20.06% TypedArrays-JoinBigIntTypes 7258 8586 18.30% TypedArrays-JoinFloatTypes 24461 28628 17.04% TypedArrays-JoinFloatTypes 24523 29647 20.89% TypedArrays-JoinFloatTypes 24419 29327 20.10% TypedArrays-JoinIntTypes 23378 33928 45.13% TypedArrays-JoinIntTypes 23333 34034 45.86% TypedArrays-JoinIntTypes 21653 34000 57.02% TypedArrays-JoinWithSeparatorBigIntTypes 6620 7339 10.86% TypedArrays-JoinWithSeparatorBigIntTypes 6566 7579 15.43% TypedArrays-JoinWithSeparatorBigIntTypes 6631 7481 12.82% TypedArrays-JoinWithSeparatorFloatTypes 18695 19670 5.22% TypedArrays-JoinWithSeparatorFloatTypes 18518 20088 8.48% TypedArrays-JoinWithSeparatorFloatTypes 18482 20193 9.26% TypedArrays-JoinWithSeparatorIntTypes 17849 21482 20.35% TypedArrays-JoinWithSeparatorIntTypes 17831 21578 21.01% TypedArrays-JoinWithSeparatorIntTypes 17937 21578 20.30% Drive-by: Removed unused CSA helper InternalArrayCreate. Bug: v8:7624 Change-Id: I8e63815982439cfd2267417d03cd2b71b4b7a812 Reviewed-on: https://chromium-review.googlesource.com/c/1369330 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58167}
2018-12-11 15:27:31 +00:00
CastHeapObject<JSTypedArray>(o: HeapObject): JSTypedArray
labels CastError {
if (IsJSTypedArray(o)) return %RawObjectCast<JSTypedArray>(o);
goto CastError;
}
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<Callable>(o: HeapObject): Callable
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return HeapObjectToCallable(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
CastHeapObject<JSArray>(o: HeapObject): JSArray
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return HeapObjectToJSArray(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
CastHeapObject<Context>(o: HeapObject): Context
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsContext(o)) return %RawObjectCast<Context>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<JSObject>(o: HeapObject): JSObject
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsJSObject(o)) return %RawObjectCast<JSObject>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<NumberDictionary>(o: HeapObject): NumberDictionary
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsNumberDictionary(o)) return %RawObjectCast<NumberDictionary>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<FixedTypedArrayBase>(o: HeapObject): FixedTypedArrayBase
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsFixedTypedArray(o)) return %RawObjectCast<FixedTypedArrayBase>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
CastHeapObject<String>(o: HeapObject): String
labels CastError {
return HeapObjectToString(o) otherwise CastError;
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
Port Array.of to Torque 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/1296464 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56935}
2018-10-24 09:31:21 +00:00
CastHeapObject<Constructor>(o: HeapObject): Constructor
labels CastError {
return HeapObjectToConstructor(o) otherwise CastError;
}
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
CastHeapObject<HeapNumber>(o: HeapObject): HeapNumber
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsHeapNumber(o)) return %RawObjectCast<HeapNumber>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<Map>(implicit context: Context)(o: HeapObject): Map
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsMap(o)) return %RawObjectCast<Map>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<JSArgumentsObjectWithLength>(implicit context: Context)(
o: HeapObject): JSArgumentsObjectWithLength
labels CastError {
const map: Map = o.map;
try {
if (IsFastAliasedArgumentsMap(map)) goto True;
if (IsSloppyArgumentsMap(map)) goto True;
if (IsStrictArgumentsMap(map)) goto True;
if (IsSlowAliasedArgumentsMap(map)) goto True;
goto CastError;
}
label True {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
return %RawObjectCast<JSArgumentsObjectWithLength>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
}
}
CastHeapObject<FastJSArray>(implicit context: Context)(o: HeapObject):
FastJSArray
labels CastError {
const map: Map = o.map;
if (!IsJSArrayMap(map)) goto CastError;
// Bailout if receiver has slow elements.
const elementsKind: ElementsKind = LoadMapElementsKind(map);
if (!IsFastElementsKind(elementsKind)) goto CastError;
// Verify that our prototype is the initial array prototype.
if (!IsPrototypeInitialArrayPrototype(map)) goto CastError;
if (IsNoElementsProtectorCellInvalid()) goto CastError;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
return %RawObjectCast<FastJSArray>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
}
[Torque] Array.prototype.filter moves to Torque. 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}
2019-01-08 14:49:43 +00:00
struct FastJSArrayWitness {
array: HeapObject;
map: Map;
}
macro MakeWitness(array: FastJSArray): FastJSArrayWitness {
return FastJSArrayWitness{array, array.map};
}
macro Testify(witness: FastJSArrayWitness): FastJSArray labels CastError {
if (witness.array.map != witness.map) goto CastError;
// We don't need to check elements kind or whether the prototype
// has changed away from the default JSArray prototype, because
// if the map remains the same then those properties hold.
//
// However, we have to make sure there are no elements in the
// prototype chain.
if (IsNoElementsProtectorCellInvalid()) goto CastError;
return %RawObjectCast<FastJSArray>(witness.array);
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
CastHeapObject<FastJSArrayForCopy>(implicit context: Context)(o: HeapObject):
FastJSArrayForCopy
labels CastError {
if (IsArraySpeciesProtectorCellInvalid()) goto CastError;
const a: FastJSArray = Cast<FastJSArray>(o) otherwise CastError;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
return %RawObjectCast<FastJSArrayForCopy>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
}
CastHeapObject<FastJSArrayWithNoCustomIteration>(implicit context: Context)(
o: HeapObject): FastJSArrayWithNoCustomIteration
labels CastError {
if (IsArrayIteratorProtectorCellInvalid()) goto CastError;
const a: FastJSArray = Cast<FastJSArray>(o) otherwise CastError;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
return %RawObjectCast<FastJSArrayWithNoCustomIteration>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
}
CastHeapObject<JSReceiver>(implicit context: Context)(o: HeapObject): JSReceiver
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsJSReceiver(o)) return %RawObjectCast<JSReceiver>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
CastHeapObject<JSFunction>(implicit context: Context)(o: HeapObject): JSFunction
labels CastError {
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
if (IsJSFunction(o)) return %RawObjectCast<JSFunction>(o);
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
goto CastError;
}
macro Cast<A: type>(implicit context: Context)(o: HeapObject): A
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels CastError {
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
return CastHeapObject<A>(o) otherwise CastError;
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
}
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
// CastHeapObject allows this default-implementation to be non-recursive.
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
// Otherwise the generated CSA code might run into infinite recursion.
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
macro Cast<A: type>(implicit context: Context)(o: Object): A
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels CastError {
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
return CastHeapObject<A>(TaggedToHeapObject(o) otherwise CastError)
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
Cast<Smi>(o: Object): Smi
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return TaggedToSmi(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
Cast<Number>(o: Object): Number
labels CastError {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return TaggedToNumber(o) otherwise CastError;
[torque] Implement parameter overloading in generics This allows redifinitions of generics with the same name but differing parameter type lists, e.g. macro coerce<Dest: type>(from: HeapObject): Dest; coerce<int32>(from: HeapObject): int32 {...} macro coerce<Dest: type>(from: Smi): Dest; coerce<int32>(from: Smi): int32 {...} In order to allow multiple overloads of generic macros with the same name, a more nuanced lookup of calls has been implemented using the ParameterDifference utility class. There is still work to be done to unify when ParameterDifference is used for lookup (e.g. removing it from operator lookup when operators become simple aliases for macro names), but that work will be done in a separate CL. As part of this CL, the custom handling of "cast<>" operator in the .g4 grammar has been removed and replaced by a handful of equivalent overloads of a generic "cast" macro. Bug: v8:7793 Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8 Reviewed-on: https://chromium-review.googlesource.com/1087873 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53562}
2018-06-06 15:35:39 +00:00
}
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro AllocateHeapNumberWithValue(float64): HeapNumber;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro ChangeInt32ToTagged(int32): Number;
extern macro ChangeUint32ToTagged(uint32): Number;
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
extern macro ChangeUintPtrToFloat64(uintptr): float64;
extern macro ChangeUintPtrToTagged(uintptr): Number;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Unsigned(int32): uint32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Unsigned(intptr): uintptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Unsigned(RawPtr): uintptr;
extern macro Signed(uint32): int32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Signed(uintptr): intptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Signed(RawPtr): intptr;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro TruncateIntPtrToInt32(intptr): int32;
extern macro SmiTag(intptr): Smi;
extern macro SmiFromInt32(int32): Smi;
extern macro SmiUntag(Smi): intptr;
extern macro SmiToInt32(Smi): int32;
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
extern macro RoundIntPtrToFloat64(intptr): float64;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro LoadHeapNumberValue(HeapNumber): float64;
extern macro ChangeFloat32ToFloat64(float32): float64;
extern macro ChangeNumberToFloat64(Number): float64;
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
extern macro ChangeFloat64ToUintPtr(float64): uintptr;
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
extern macro ChangeInt32ToIntPtr(int32): intptr; // Sign-extends.
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro ChangeUint32ToWord(uint32): uintptr; // Doesn't sign-extend.
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
extern macro LoadNativeContext(Context): NativeContext;
extern macro LoadJSArrayElementsMap(constexpr ElementsKind, Context): Map;
[Torque] Array.prototype.filter moves to Torque. 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}
2019-01-08 14:49:43 +00:00
extern macro LoadJSArrayElementsMap(ElementsKind, Context): Map;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro ChangeNonnegativeNumberToUintPtr(Number): uintptr;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro NumberConstant(constexpr float64): Number;
extern macro NumberConstant(constexpr int32): Number;
[builtin] Array.p.join throws on invalid Array lengths. This matches the pre-torque behavior when the receiver's length was greater than the max array length. Bug: chromium:902672 Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203 Reviewed-on: https://chromium-review.googlesource.com/c/1330921 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57456}
2018-11-13 08:58:09 +00:00
extern macro NumberConstant(constexpr uint32): Number;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro IntPtrConstant(constexpr int31): intptr;
extern macro IntPtrConstant(constexpr int32): intptr;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro Int32Constant(constexpr int31): int31;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro Int32Constant(constexpr int32): int32;
[dataview][cleanup] Encapsulate BigInt allocation logic in data-view.tq This CL separates the BigInt allocation code in the DataView BigInt getters from the logic of the getters themselves. This makes the code much easier to read and understand. Change-Id: I9f7ee3fb819f0606dc631bac89e386f6fec43655 Reviewed-on: https://chromium-review.googlesource.com/1107632 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54036}
2018-06-26 13:55:16 +00:00
extern macro Float64Constant(constexpr int31): float64;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro SmiConstant(constexpr int31): Smi;
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern macro SmiConstant(constexpr Smi): Smi;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro BoolConstant(constexpr bool): bool;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro StringConstant(constexpr string): String;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro LanguageModeConstant(constexpr LanguageMode): LanguageMode;
extern macro Int32Constant(constexpr ElementsKind): ElementsKind;
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
extern macro IntPtrConstant(constexpr NativeContextSlot): NativeContextSlot;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
extern macro IntPtrConstant(constexpr intptr): intptr;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
extern macro BitcastWordToTaggedSigned(intptr): Smi;
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern macro BitcastWordToTaggedSigned(uintptr): Smi;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
extern macro BitcastWordToTagged(intptr): Object;
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
extern macro BitcastWordToTagged(uintptr): Object;
extern macro BitcastTaggedToWord(Tagged): intptr;
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
intrinsic %FromConstexpr<To: type, From: type>(b: From): To;
macro FromConstexpr<To: type, From: type>(o: From): To;
FromConstexpr<int31, constexpr int31>(i: constexpr int31): int31 {
return %FromConstexpr<int31>(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<int32, constexpr int31>(i: constexpr int31): int32 {
return %FromConstexpr<int32>(i);
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<int32, constexpr int32>(i: constexpr int32): int32 {
return %FromConstexpr<int32>(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<intptr, constexpr int31>(i: constexpr int31): intptr {
return %FromConstexpr<intptr>(i);
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<intptr, constexpr int32>(i: constexpr int32): intptr {
return %FromConstexpr<intptr>(i);
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
}
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
FromConstexpr<intptr, constexpr intptr>(i: constexpr intptr): intptr {
return %FromConstexpr<intptr>(i);
}
FromConstexpr<uintptr, constexpr uintptr>(i: constexpr uintptr): uintptr {
return %FromConstexpr<uintptr>(i);
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Smi, constexpr int31>(i: constexpr int31): Smi {
return %FromConstexpr<Smi>(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<String, constexpr string>(s: constexpr string): String {
return %FromConstexpr<String>(s);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Number, constexpr uint32>(i: constexpr uint32): Number {
return %FromConstexpr<Number>(i);
[dataview][cleanup] Encapsulate BigInt allocation logic in data-view.tq This CL separates the BigInt allocation code in the DataView BigInt getters from the logic of the getters themselves. This makes the code much easier to read and understand. Change-Id: I9f7ee3fb819f0606dc631bac89e386f6fec43655 Reviewed-on: https://chromium-review.googlesource.com/1107632 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54036}
2018-06-26 13:55:16 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Number, constexpr int32>(i: constexpr int32): Number {
return %FromConstexpr<Number>(i);
[builtin] Array.p.join throws on invalid Array lengths. This matches the pre-torque behavior when the receiver's length was greater than the max array length. Bug: chromium:902672 Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203 Reviewed-on: https://chromium-review.googlesource.com/c/1330921 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57456}
2018-11-13 08:58:09 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Number, constexpr float64>(f: constexpr float64): Number {
return %FromConstexpr<Number>(f);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Number, constexpr int31>(i: constexpr int31): Number {
return %FromConstexpr<Number>(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
FromConstexpr<Number, constexpr Smi>(s: constexpr Smi): Number {
return SmiConstant(s);
}
FromConstexpr<Smi, constexpr Smi>(s: constexpr Smi): Smi {
return SmiConstant(s);
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<uint32, constexpr int31>(i: constexpr int31): uint32 {
return Unsigned(Int32Constant(i));
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<uintptr, constexpr int31>(i: constexpr int31): uintptr {
return ChangeUint32ToWord(i);
}
FromConstexpr<float64, constexpr int31>(i: constexpr int31): float64 {
return Float64Constant(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<bool, constexpr bool>(b: constexpr bool): bool {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return BoolConstant(b);
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<LanguageMode, constexpr LanguageMode>(m: constexpr LanguageMode):
LanguageMode {
return %RawObjectCast<LanguageMode>(%FromConstexpr<Smi>(m));
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<ElementsKind, constexpr ElementsKind>(e: constexpr ElementsKind):
ElementsKind {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return Int32Constant(e);
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<Object, constexpr string>(s: constexpr string): Object {
[torque] Add constexpr String handling to Torque This CL adds a 'constexpr String' type to Torque, which gets compiled to 'const char*'. It makes it easier to pass strings around in Torque files, especially when trying to Print() them. Bug: v8:7793 Change-Id: I2d4feac7012f5401f2b467475f8df086e46ac18a Reviewed-on: https://chromium-review.googlesource.com/1104466 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53814}
2018-06-18 15:50:59 +00:00
return StringConstant(s);
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
FromConstexpr<NativeContextSlot, constexpr NativeContextSlot>(
c: constexpr NativeContextSlot): NativeContextSlot {
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
return IntPtrConstant(c);
}
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
macro Convert<To: type, From: type>(i: From): To {
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
return i;
}
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
extern macro ConvertElementsKindToInt(ElementsKind): int32;
Convert<int32, ElementsKind>(elementsKind: ElementsKind): int32 {
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
return ConvertElementsKindToInt(elementsKind);
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Number, int32>(i: int32): Number {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return ChangeInt32ToTagged(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<intptr, int32>(i: int32): intptr {
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
return ChangeInt32ToIntPtr(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Smi, int32>(i: int32): Smi {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return SmiFromInt32(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Number, uint32>(ui: uint32): Number {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return ChangeUint32ToTagged(ui);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Smi, uint32>(ui: uint32): Smi {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return SmiFromInt32(Signed(ui));
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uintptr, uint32>(ui: uint32): uintptr {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return ChangeUint32ToWord(ui);
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<int32, intptr>(i: intptr): int32 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return TruncateIntPtrToInt32(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Smi, intptr>(i: intptr): Smi {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return SmiTag(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uint32, uintptr>(ui: uintptr): uint32 {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return Unsigned(TruncateIntPtrToInt32(Signed(ui)));
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<intptr, Smi>(s: Smi): intptr {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return SmiUntag(s);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<int32, Smi>(s: Smi): int32 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return SmiToInt32(s);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<float64, HeapNumber>(h: HeapNumber): float64 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return LoadHeapNumberValue(h);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<float64, Number>(n: Number): float64 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return ChangeNumberToFloat64(n);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uintptr, Number>(n: Number): uintptr {
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
return ChangeNonnegativeNumberToUintPtr(n);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<float64, float32>(f: float32): float64 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return ChangeFloat32ToFloat64(f);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Number, float64>(d: float64): Number {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return AllocateHeapNumberWithValue(d);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<float64, uintptr>(ui: uintptr): float64 {
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
return ChangeUintPtrToFloat64(ui);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<Number, uintptr>(ui: uintptr): Number {
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
return ChangeUintPtrToTagged(ui);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uintptr, float64>(d: float64): uintptr {
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
return ChangeFloat64ToUintPtr(d);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uintptr, intptr>(i: intptr): uintptr {
[builtins] Port Frame-related CSA functionality to Torque Moving Frame-inspection functionality to Torque is a prerequisite for porting the CSA-based arguments code, which is a great candidate to simplify/cleanup with Torque. Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8 Reviewed-on: https://chromium-review.googlesource.com/c/1357050 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@{#58106}
2018-12-07 16:29:49 +00:00
return Unsigned(i);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<uintptr, RawPtr>(r: RawPtr): uintptr {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return Unsigned(r);
}
[torque] Simplify Convert<> Bug: v8:7793 Change-Id: I31cae67edfce6a0ba925df34d496d3d62bc7d5ef Reviewed-on: https://chromium-review.googlesource.com/c/1358519 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58114}
2018-12-09 21:12:45 +00:00
Convert<intptr, RawPtr>(r: RawPtr): intptr {
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
return Signed(r);
}
[builtins] Port GetArgumentsFrameAndCount to Torque In the process, add the bint type (which stands for Best-INTeger), which implements Torque's idea of CSA's ParameterMode. It maps to a different type on 32-bit (Smi) and 64-bit (intptr). There are convert operators that are either no-ops or conversions to-and-from Smi and intptrs on the each platform, depending on the underlying type for bint. This allows Torque code to git most of the benefits of ParameterMode without having to explicitly pass around the mode, since it is almost always OptimalMode anyways. Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162 Reviewed-on: https://chromium-review.googlesource.com/c/1361160 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@{#58253}
2018-12-14 19:35:34 +00:00
Convert<bint, int32>(v: int32): bint {
return IntPtrToBInt(Convert<intptr>(v));
}
extern macro IntPtrToBInt(intptr): bint;
Convert<bint, intptr>(v: intptr): bint {
return IntPtrToBInt(v);
}
extern macro SmiToBInt(Smi): bint;
Convert<bint, Smi>(v: Smi): bint {
return SmiToBInt(v);
}
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
macro BranchIf<A: type, B: type>(implicit context: Context)(o: B): never
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
labels True, False {
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
Cast<A>(o) otherwise False;
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
goto True;
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
macro BranchIfNot<A: type, B: type>(implicit context: Context)(o: B): never
labels True, False {
Cast<A>(o) otherwise True;
goto False;
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
macro Is<A: type, B: type>(implicit context: Context)(o: B): bool {
return (BranchIf<A, B>(o)) ? true : false;
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
macro UnsafeCast<A: type>(implicit context: Context)(o: Object): A {
assert(Is<A>(o));
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
return %RawObjectCast<A>(o);
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
UnsafeCast<Object>(o: Object): Object {
return o;
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
}
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
const kCOWMap: Map = %RawObjectCast<Map>(LoadRoot(kFixedCOWArrayMapRootIndex));
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
const kEmptyFixedArray: FixedArrayBase =
[torque] Add new and refine existing Torque intrinsic support Intrinsic changes: - Rename %RawCast to %RawObjectCast and add error checking so that it only applies to subtypes of Objects. - Add %RawPointerCast, which is similar to %RawObjectCast but must be used for all subtypes of RawPtr. - Add %RawConstexprCast, which allows one constexpr to be be cast to another at compile time. It translate to an appropriate static_cast in the generated code - Add %FromConstexpr, which handles most of the standard cases of generating XXXConstant CSA nodes from constexpr constants. It uses either SmiConstant, NumberConstant, StringConstant, IntPtrConstant or Int32Constant, depending on the cast-to type generic <To> type. - Add support for intrinsics that return constexpr results. Cleanup: - Turn FromConstexpr into a generic with two generic types, a <To> and a <From> type. Most FromConstexpr can use the new %FromConstexpr intrinsic rather than provide an explicit implementation. Bug: v8:7793 Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464 Reviewed-on: https://chromium-review.googlesource.com/c/1357049 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58049}
2018-12-05 18:23:55 +00:00
%RawObjectCast<FixedArrayBase>(LoadRoot(kEmptyFixedArrayRootIndex));
[array] Move Array.p.lastIndexOf from JS to Torque This CL re-implements Array.p.lastIndexOf in Torque. The implementation consists of a generic baseline path and a fast-path for JSArrays with fast ElementsKinds. Sparse support for JSArrays was removed. Bug: v8:7624 Change-Id: I6ae877aaf99fa97a91763b3d60a0ee05623ab085 Reviewed-on: https://chromium-review.googlesource.com/1190345 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55451}
2018-08-28 09:14:58 +00:00
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro IsPrototypeInitialArrayPrototype(implicit context: Context)(Map):
bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsNoElementsProtectorCellInvalid(): bool;
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro IsArrayIteratorProtectorCellInvalid(): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsArraySpeciesProtectorCellInvalid(): bool;
extern macro IsTypedArraySpeciesProtectorCellInvalid(): bool;
extern macro IsPromiseSpeciesProtectorCellInvalid(): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] qualified access to CSA assemblers 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}
2018-11-05 11:59:29 +00:00
extern operator '.buffer' macro
TypedArrayBuiltinsAssembler::LoadTypedArrayBuffer(JSTypedArray): JSArrayBuffer;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[torque] qualified access to CSA assemblers 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}
2018-11-05 11:59:29 +00:00
extern operator '.data_ptr' macro TypedArrayBuiltinsAssembler::LoadDataPtr(
JSTypedArray): RawPtr;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '.elements_kind' macro LoadMapElementsKind(Map): ElementsKind;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '.elements_kind' macro LoadElementsKind(JSTypedArray):
ElementsKind;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
extern operator '.elements' macro LoadElements(JSObject): FixedArrayBase;
extern operator '.elements=' macro StoreElements(JSObject, FixedArrayBase);
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[es2015] Change JSArrayBufferView::byte_length/byte_offset to uintptr_t. 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/1228377 Reviewed-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}
2018-09-18 17:47:28 +00:00
extern operator '.length' macro LoadJSTypedArrayLength(JSTypedArray): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '.length' macro LoadJSArrayLength(JSArray): Number;
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
extern operator '.length' macro LoadJSArgumentsObjectWithLength(
JSArgumentsObjectWithLength): Object;
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
extern operator '.length' macro LoadFastJSArrayLength(FastJSArray): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '.length=' macro StoreJSArrayLength(JSArray, Smi);
extern operator '.length' macro LoadFixedArrayBaseLength(FixedArrayBase): Smi;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern operator '.length_intptr' macro LoadAndUntagFixedArrayBaseLength(
FixedArrayBase): intptr;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '[]' macro LoadFixedArrayElement(FixedArray, intptr): Object;
extern operator '[]' macro LoadFixedArrayElement(FixedArray, Smi): Object;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '[]' macro LoadFixedArrayElement(
FixedArray, constexpr int31): Object;
extern operator '[]=' macro StoreFixedArrayElement(
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
FixedArray, intptr, Smi): void;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '[]=' macro StoreFixedArrayElement(
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
FixedArray, intptr, HeapObject): void;
extern operator '[]=' macro StoreFixedArrayElement(
FixedArray, constexpr int31, Smi): void;
extern operator '[]=' macro StoreFixedArrayElement(
FixedArray, constexpr int31, HeapObject): void;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '[]=' macro StoreFixedArrayElementSmi(
FixedArray, Smi, Object): void;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
operator '[]=' macro StoreFixedDoubleArrayNumber(
a: FixedDoubleArray, index: Smi, value: Number): void {
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
a[index] = Convert<float64>(value);
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
}
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro StoreFixedArrayElementSmi(
FixedArray, Smi, Object, constexpr WriteBarrierMode): void;
[array] Skip write barrier when sorting packed Smis R=jgruber@chromium.org Bug: chromium:873555 Change-Id: I6268bedf47a89194875d1179e603bcfe972c9d68 Reviewed-on: https://chromium-review.googlesource.com/1172282 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#55077}
2018-08-13 08:43:56 +00:00
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern operator '.instance_type' macro LoadMapInstanceType(Map): int32;
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
extern operator '.prototype_or_initial_map' macro
LoadJSFunctionPrototypeOrInitialMap(JSFunction): Object;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
extern macro LoadFixedDoubleArrayElement(FixedDoubleArray, Smi): float64;
extern macro Float64SilenceNaN(float64): float64;
extern macro StoreFixedDoubleArrayElement(
FixedDoubleArray, Object, float64, constexpr ParameterMode);
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro StoreFixedArrayElement(
FixedArray, intptr, Object, constexpr WriteBarrierMode): void;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
macro StoreFixedDoubleArrayElementWithSmiIndex(
array: FixedDoubleArray, index: Smi, value: float64) {
StoreFixedDoubleArrayElement(array, index, value, SMI_PARAMETERS);
}
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro GetNumberDictionaryNumberOfElements(NumberDictionary): Smi;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro BasicLoadNumberDictionaryElement(NumberDictionary, intptr): Object
labels NotData, IfHole;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro BasicStoreNumberDictionaryElement(NumberDictionary, intptr, Object)
[Torque] Rename modules to namespaces BUG=v8:7793 Change-Id: Ibcf16998ef9a44ae899a2536ccf02af1b7b7193d Reviewed-on: https://chromium-review.googlesource.com/c/1333410 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57469}
2018-11-13 13:00:34 +00:00
labels NotData, IfHole, ReadOnly;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsFastElementsKind(ElementsKind): bool;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro IsDoubleElementsKind(ElementsKind): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsFastSmiOrTaggedElementsKind(ElementsKind): bool;
extern macro IsFastSmiElementsKind(ElementsKind): bool;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro IsHoleyFastElementsKind(ElementsKind): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
macro AllowDoubleElements(kind: ElementsKind): ElementsKind {
if (kind == PACKED_SMI_ELEMENTS) {
return PACKED_DOUBLE_ELEMENTS;
} else if (kind == HOLEY_SMI_ELEMENTS) {
return HOLEY_DOUBLE_ELEMENTS;
}
return kind;
}
macro AllowNonNumberElements(kind: ElementsKind): ElementsKind {
if (kind == PACKED_SMI_ELEMENTS) {
return PACKED_ELEMENTS;
} else if (kind == HOLEY_SMI_ELEMENTS) {
return HOLEY_ELEMENTS;
} else if (kind == PACKED_DOUBLE_ELEMENTS) {
return PACKED_ELEMENTS;
} else if (kind == HOLEY_DOUBLE_ELEMENTS) {
return HOLEY_ELEMENTS;
}
return kind;
}
[torque] only expose safe FixedArray allocation drive-by change: fix wrong typing in CSA. Change-Id: I9234306e8568a64157b44a86a58f09e65116b298 Reviewed-on: https://chromium-review.googlesource.com/1172583 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55093}
2018-08-13 15:08:55 +00:00
extern macro AllocateZeroedFixedArray(intptr): FixedArray;
extern macro AllocateZeroedFixedDoubleArray(intptr): FixedDoubleArray;
[Builtins] Array.prototype.splice performance improvements a) The current size of the backing store for the array under splice wasn't considered. Additionally, allocate the array with the normal growing strategy. b) Use primitives memcpy and memmove when appropriate. These calls are wrapped in new CSA functions MoveElements and CopyElements, which use the C functions when a write barrier isn't needed (otherwise they just copy elements in a loop). Bug: chromium:880780 Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67 Reviewed-on: https://chromium-review.googlesource.com/c/1243104 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56534}
2018-10-10 14:39:19 +00:00
extern macro CalculateNewElementsCapacity(Smi): Smi;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro CalculateNewElementsCapacity(intptr): intptr;
[Builtins] Array.prototype.splice performance improvements a) The current size of the backing store for the array under splice wasn't considered. Additionally, allocate the array with the normal growing strategy. b) Use primitives memcpy and memmove when appropriate. These calls are wrapped in new CSA functions MoveElements and CopyElements, which use the C functions when a write barrier isn't needed (otherwise they just copy elements in a loop). Bug: chromium:880780 Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67 Reviewed-on: https://chromium-review.googlesource.com/c/1243104 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56534}
2018-10-10 14:39:19 +00:00
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro AllocateFixedArrayWithHoles(
intptr, constexpr AllocationFlags): FixedArray;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro CopyFixedArrayElements(
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
constexpr ElementsKind, FixedArray, constexpr ElementsKind, FixedArray,
intptr, intptr, intptr): void;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro CopyFixedArrayElements(
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
constexpr ElementsKind, FixedArray, constexpr ElementsKind, FixedArray, Smi,
Smi, Smi): void;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro AllocateJSArray(constexpr ElementsKind, Map, intptr, Smi): JSArray;
extern macro AllocateJSArray(constexpr ElementsKind, Map, Smi, Smi): JSArray;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
extern macro AllocateJSObjectFromMap(Map): JSObject;
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern operator '[]=' macro StoreFixedDoubleArrayElementSmi(
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
FixedDoubleArray, Smi, float64): void;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro LoadDoubleWithHoleCheck(FixedDoubleArray, Smi): float64
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels IfHole;
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro LoadDoubleWithHoleCheck(FixedDoubleArray, intptr): float64
labels IfHole;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro StoreFixedDoubleArrayHoleSmi(FixedDoubleArray, Smi): void;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
macro GetObjectFunction(implicit context: Context)(): JSFunction {
return UnsafeCast<JSFunction>(
LoadNativeContext(context)[OBJECT_FUNCTION_INDEX]);
}
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning macro Call(Context, Callable, Object): Object;
extern transitioning macro Call(Context, Callable, Object, Object): Object;
extern transitioning macro Call(
Context, Callable, Object, Object, Object): Object;
extern transitioning macro Call(
Context, Callable, Object, Object, Object, Object): Object;
extern transitioning macro Call(
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
Context, Callable, Object, Object, Object, Object, Object): Object;
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
extern transitioning macro Call(
[Torque] Turn Torque HasProperty usage into builtin calls The CSA HasProperty has an inlining that makes it rather large. Also, tighten up some type usage. ToObject() returns a JSReceiver and we can do with less casting if we make use of this. Change-Id: I56d2443b5d409314cc3c74a5a079810d857727ad Reviewed-on: https://chromium-review.googlesource.com/1165241 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54951}
2018-08-07 15:49:03 +00:00
Context, Callable, Object, Object, Object, Object, Object, Object): Object;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
extern builtin CloneFastJSArray(Context, FastJSArrayForCopy): JSArray;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro ExtractFixedArray(FixedArrayBase, Smi, Smi, Smi): FixedArrayBase;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro ExtractFixedArray(
FixedArrayBase, Smi, Smi, Smi,
[array] Move Array.p.unshift fall-back to Torque This CL implements a generic baseline version of Array.p.unshift in Torque, enabling us to remove the JS fall-back. The elements-accessor fast-path is still used, but the check whether to use it is also moved to Torque. Support for sparse JSArrays is removed. Drive-by change: Small refactoring in builtins-array that will get extended to other array builtins in a follow-up CL. R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7624 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7b23ce15e7b922eb333f61a408050dedec77c95a Reviewed-on: https://chromium-review.googlesource.com/1189902 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55670}
2018-09-06 05:47:23 +00:00
constexpr ExtractFixedArrayFlags): FixedArrayBase;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro ExtractFixedArray(
FixedArray, intptr, intptr, intptr,
constexpr ExtractFixedArrayFlags): FixedArray;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern builtin ExtractFastJSArray(Context, JSArray, Smi, Smi): JSArray;
[Builtins] Array.prototype.splice performance improvements a) The current size of the backing store for the array under splice wasn't considered. Additionally, allocate the array with the normal growing strategy. b) Use primitives memcpy and memmove when appropriate. These calls are wrapped in new CSA functions MoveElements and CopyElements, which use the C functions when a write barrier isn't needed (otherwise they just copy elements in a loop). Bug: chromium:880780 Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67 Reviewed-on: https://chromium-review.googlesource.com/c/1243104 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56534}
2018-10-10 14:39:19 +00:00
extern macro MoveElements(
constexpr ElementsKind, FixedArrayBase, intptr, intptr, intptr): void;
macro TorqueMoveElements(
elements: FixedArray, dstIndex: intptr, srcIndex: intptr,
count: intptr): void {
MoveElements(HOLEY_ELEMENTS, elements, dstIndex, srcIndex, count);
}
macro TorqueMoveElements(
elements: FixedDoubleArray, dstIndex: intptr, srcIndex: intptr,
count: intptr): void {
MoveElements(HOLEY_DOUBLE_ELEMENTS, elements, dstIndex, srcIndex, count);
}
extern macro CopyElements(
constexpr ElementsKind, FixedArrayBase, intptr, FixedArrayBase, intptr,
intptr): void;
macro TorqueCopyElements(
dstElements: FixedArray, dstIndex: intptr, srcElements: FixedArray,
srcIndex: intptr, count: intptr): void {
CopyElements(
HOLEY_ELEMENTS, dstElements, dstIndex, srcElements, srcIndex, count);
}
macro TorqueCopyElements(
dstElements: FixedDoubleArray, dstIndex: intptr,
srcElements: FixedDoubleArray, srcIndex: intptr, count: intptr): void {
CopyElements(
HOLEY_DOUBLE_ELEMENTS, dstElements, dstIndex, srcElements, srcIndex,
count);
}
[Torque] Array.prototype.filter moves to Torque. 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}
2019-01-08 14:49:43 +00:00
macro LoadElementNoHole<T: type>(a: JSArray, index: Smi): Object
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels IfHole;
[Builtins] Cleanup of Array.prototype.forEach() Making it into more "idiomatic" Torque code (we are still defining what that means). Template specialization on double and fast fixed arrays allowed me to cut down on the boilerplate. Bug: v8:7672 Change-Id: Ia35706993a9e2ea087ecc3ef93b3a5864ec97827 Reviewed-on: https://chromium-review.googlesource.com/1064054 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53246}
2018-05-18 08:23:25 +00:00
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
LoadElementNoHole<FixedArray>(implicit context: Context)(
a: JSArray, index: Smi): Object
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels IfHole {
[Builtins] Cleanup of Array.prototype.forEach() Making it into more "idiomatic" Torque code (we are still defining what that means). Template specialization on double and fast fixed arrays allowed me to cut down on the boilerplate. Bug: v8:7672 Change-Id: Ia35706993a9e2ea087ecc3ef93b3a5864ec97827 Reviewed-on: https://chromium-review.googlesource.com/1064054 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53246}
2018-05-18 08:23:25 +00:00
try {
let elements: FixedArray =
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
Cast<FixedArray>(a.elements) otherwise Unexpected;
[Builtins] Cleanup of Array.prototype.forEach() Making it into more "idiomatic" Torque code (we are still defining what that means). Template specialization on double and fast fixed arrays allowed me to cut down on the boilerplate. Bug: v8:7672 Change-Id: Ia35706993a9e2ea087ecc3ef93b3a5864ec97827 Reviewed-on: https://chromium-review.googlesource.com/1064054 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53246}
2018-05-18 08:23:25 +00:00
let e: Object = elements[index];
if (e == Hole) {
goto IfHole;
}
return e;
}
label Unexpected {
unreachable;
}
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
LoadElementNoHole<FixedDoubleArray>(implicit context: Context)(
a: JSArray, index: Smi): Object
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
labels IfHole {
[Builtins] Cleanup of Array.prototype.forEach() Making it into more "idiomatic" Torque code (we are still defining what that means). Template specialization on double and fast fixed arrays allowed me to cut down on the boilerplate. Bug: v8:7672 Change-Id: Ia35706993a9e2ea087ecc3ef93b3a5864ec97827 Reviewed-on: https://chromium-review.googlesource.com/1064054 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53246}
2018-05-18 08:23:25 +00:00
try {
let elements: FixedDoubleArray =
[torque] Fix all current lint errors in Torque code To make the changes in base.tq work, there were 2 changes needed on the C++ side: - calls to "FromConstexpr" are generated by the compiler for implicit conversions. - type switch is desugared and uses "Cast" R=jgruber@chromium.org, tebbi@chromium.org Change-Id: I085f1a393f93e501e6bbcaeacb0d6568259a4714 Reviewed-on: https://chromium-review.googlesource.com/1219629 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55794}
2018-09-11 13:15:02 +00:00
Cast<FixedDoubleArray>(a.elements) otherwise Unexpected;
[Builtins] Cleanup of Array.prototype.forEach() Making it into more "idiomatic" Torque code (we are still defining what that means). Template specialization on double and fast fixed arrays allowed me to cut down on the boilerplate. Bug: v8:7672 Change-Id: Ia35706993a9e2ea087ecc3ef93b3a5864ec97827 Reviewed-on: https://chromium-review.googlesource.com/1064054 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53246}
2018-05-18 08:23:25 +00:00
let e: float64 = LoadDoubleWithHoleCheck(elements, index) otherwise IfHole;
return AllocateHeapNumberWithValue(e);
}
label Unexpected {
unreachable;
}
}
[Torque] Rename modules to namespaces BUG=v8:7793 Change-Id: Ibcf16998ef9a44ae899a2536ccf02af1b7b7193d Reviewed-on: https://chromium-review.googlesource.com/c/1333410 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57469}
2018-11-13 13:00:34 +00:00
extern macro TransitionElementsKind(
JSObject, Map, ElementsKind, ElementsKind): void labels Bailout;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsCallable(HeapObject): bool;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
extern macro IsJSArray(HeapObject): bool;
Add torque/csa functionality in preparation for Object.fromEntries Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57425}
2018-11-12 09:27:20 +00:00
extern macro IsMap(HeapObject): bool;
extern macro IsJSFunction(HeapObject): bool;
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro IsJSObject(HeapObject): bool;
[builtins] Port TypedArray join, toString, and toLocaleString to Torque. Micro-benchmarks show speed improvements across the various types: TypedArrays-JoinBigIntTypes 7246 8297 14.50% TypedArrays-JoinBigIntTypes 7194 8637 20.06% TypedArrays-JoinBigIntTypes 7258 8586 18.30% TypedArrays-JoinFloatTypes 24461 28628 17.04% TypedArrays-JoinFloatTypes 24523 29647 20.89% TypedArrays-JoinFloatTypes 24419 29327 20.10% TypedArrays-JoinIntTypes 23378 33928 45.13% TypedArrays-JoinIntTypes 23333 34034 45.86% TypedArrays-JoinIntTypes 21653 34000 57.02% TypedArrays-JoinWithSeparatorBigIntTypes 6620 7339 10.86% TypedArrays-JoinWithSeparatorBigIntTypes 6566 7579 15.43% TypedArrays-JoinWithSeparatorBigIntTypes 6631 7481 12.82% TypedArrays-JoinWithSeparatorFloatTypes 18695 19670 5.22% TypedArrays-JoinWithSeparatorFloatTypes 18518 20088 8.48% TypedArrays-JoinWithSeparatorFloatTypes 18482 20193 9.26% TypedArrays-JoinWithSeparatorIntTypes 17849 21482 20.35% TypedArrays-JoinWithSeparatorIntTypes 17831 21578 21.01% TypedArrays-JoinWithSeparatorIntTypes 17937 21578 20.30% Drive-by: Removed unused CSA helper InternalArrayCreate. Bug: v8:7624 Change-Id: I8e63815982439cfd2267417d03cd2b71b4b7a812 Reviewed-on: https://chromium-review.googlesource.com/c/1369330 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#58167}
2018-12-11 15:27:31 +00:00
extern macro IsJSTypedArray(HeapObject): bool;
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro IsNumberDictionary(HeapObject): bool;
extern macro IsFixedTypedArray(HeapObject): bool;
extern macro IsContext(HeapObject): bool;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro IsJSReceiver(HeapObject): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro TaggedIsCallable(Object): bool;
extern macro IsDetachedBuffer(JSArrayBuffer): bool;
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
extern macro IsHeapNumber(HeapObject): bool;
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 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}
2018-08-22 13:17:38 +00:00
extern macro IsFixedArray(HeapObject): bool;
[builtins] Enable Torque Array.prototype.splice Before, splice was implemented with a C++ fast path and a comprehensive JavaScript version. This impl. is entirely in Torque with a fastpath for SMI, DOUBLE and OBJECT arrays, and a comprehensive slow path. The same level of "sparse" array support as given by the array.js implementation is included. This reland addresses several issues: * Removed "sparse" array support from splice. * Addressed ClusterFuzz issue 876443: The test and code that uses the fix is in this CL. The fix in isolation can be seen here: https://chromium-review.googlesource.com/c/v8/v8/+/1199403 * Removed dead code in elements.cc BUG=chromium:876443, v8:8131, v8:1956, v8:7221 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1 Reviewed-on: https://chromium-review.googlesource.com/1201783 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55610}
2018-09-04 12:30:33 +00:00
extern macro IsNumber(Object): bool;
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro IsJSArrayMap(Map): bool;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro IsExtensibleMap(Map): bool;
extern macro IsCustomElementsReceiverInstanceType(int32): bool;
Reland "[builtins] Implement Object.fromEntries" This is a reland of a5336471f273a9061f1a03fdad9d78214d81a793 Original change's description: > [builtins] Implement Object.fromEntries > > Adds the Object.fromEntries() method behind > --harmony-object-from-entries. > > 
> Includes an initial implementation of the new experimental builtin > Object.fromEntries implemented by Daniel Clifford, and > has been modified by Caitlin Potter to support a fast case to skip > the iterator protocol when it can be done unobservably in common cases. > > There are some incidental changes: A number of CSA macros have been > updated to use TNodes, and some Context arguments have been > re-arranged to be implicit in Torque.
> > > There are also a number of mjsunit tests written mirroring and > expanding on the test262 tests. > > BUG=v8:8021 > > Change-Id: I1c12bee8a2f98c6297b77d5d723910a5e3b630cc > Co-authored-by: Daniel Clifford <danno@chromium.org> > Co-authored-by: Caitlin Potter <caitp@igalia.com> > Reviewed-on: https://chromium-review.googlesource.com/c/1337585 > Commit-Queue: Daniel Clifford <danno@chromium.org> > Reviewed-by: Daniel Clifford <danno@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57667} Bug: v8:8021 Change-Id: I706e2d87bfc2f688e833c1b7d40ca82f5d80f5a2 Reviewed-on: https://chromium-review.googlesource.com/c/1346630 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#57798}
2018-11-22 15:29:55 +00:00
extern macro IsFastJSArrayWithNoCustomIteration(implicit context: Context)(
Object): bool;
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
extern macro Typeof(Object): Object;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
// Return true iff number is NaN.
macro NumberIsNaN(number: Number): bool {
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
typeswitch (number) {
case (Smi): {
[torque] add typeswitch statement This adds a typeswitch statement typeswitch (e) case (x1 : Type1) { ... } case (x2 : Type2) { } ... ... case (xn : TypeN) { ... } This checks to which of the given types the result of evaluating e can be cast, in the order in which they are listed. So if an earlier type matches, a value of this type won't reach a later case. The type-checks are performed by calling the cast<T>() macro. The type of the argument passed to the cast macro is dependent on the case and excludes all types checked earlier. For example, in const x : Object = ... typeswitch (x) case (x : Smi) { ... } case (x : HeapNumber) { ... } case (x : HeapObject) { ... } there will be calls to cast<Smi>(Object) and cast<HeapNumber>(HeapObject), because after the Smi check we know that x has to be a HeapObject. With the refactored base.tq definition of cast, this will generate efficient code and avoid repeating the Smi check in the second case. The type system ensures that all cases are reachable and that the type given to the last case is safe without a runtime check (in other words, the union of all checked types covers the type of e). The cases can also be written as case (Type) { ... } , in which case the switched value is not re-bound with the checked type. Bug: v8:7793 Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3 Reviewed-on: https://chromium-review.googlesource.com/1156506 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54958}
2018-08-07 21:57:19 +00:00
return false;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
}
case (hn: HeapNumber): {
let value: float64 = Convert<float64>(hn);
return value != value;
}
[torque] a new self-contained parser for torque Bug: v8:7793 Change-Id: I208edf856f0283d840358f3c11bab97af0397056 Reviewed-on: https://chromium-review.googlesource.com/1095192 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54574}
2018-07-18 18:03:45 +00:00
}
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
}
[torque][cleanup] Move ToBoolean to base.tq This CL moves the ToBoolean function from data-view.tq to base.tq. It used to be in data-view.tq because we couldn't call macros from one file to the other but this has been fixed now, and it makes more sense to have it there. Change-Id: Id201979eacbeb4307ff7d515db48377490d5bed7 Reviewed-on: https://chromium-review.googlesource.com/1104683 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53837}
2018-06-18 16:06:22 +00:00
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
extern macro GotoIfForceSlowPath() labels Taken;
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
extern macro BranchIfToBooleanIsTrue(Object): never
labels Taken, NotTaken;
[torque][cleanup] Move ToBoolean to base.tq This CL moves the ToBoolean function from data-view.tq to base.tq. It used to be in data-view.tq because we couldn't call macros from one file to the other but this has been fixed now, and it makes more sense to have it there. Change-Id: Id201979eacbeb4307ff7d515db48377490d5bed7 Reviewed-on: https://chromium-review.googlesource.com/1104683 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53837}
2018-06-18 16:06:22 +00:00
macro ToBoolean(obj: Object): bool {
[torque]: Fix sharing of re-opened namespaces In the process, create a shared array utility GetLengthProperty that fast-paths accessing the length properties of JSArray. Bug: v8:7793 Change-Id: I6d7f0007c162794773dc0fc3e8bf12b3adf12fa0 Reviewed-on: https://chromium-review.googlesource.com/1116221 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54133}
2018-07-02 10:45:24 +00:00
if (BranchIfToBooleanIsTrue(obj)) {
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
return true;
[torque]: Fix sharing of re-opened namespaces In the process, create a shared array utility GetLengthProperty that fast-paths accessing the length properties of JSArray. Bug: v8:7793 Change-Id: I6d7f0007c162794773dc0fc3e8bf12b3adf12fa0 Reviewed-on: https://chromium-review.googlesource.com/1116221 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54133}
2018-07-02 10:45:24 +00:00
} else {
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
return false;
[torque][cleanup] Move ToBoolean to base.tq This CL moves the ToBoolean function from data-view.tq to base.tq. It used to be in data-view.tq because we couldn't call macros from one file to the other but this has been fixed now, and it makes more sense to have it there. Change-Id: Id201979eacbeb4307ff7d515db48377490d5bed7 Reviewed-on: https://chromium-review.googlesource.com/1104683 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53837}
2018-06-18 16:06:22 +00:00
}
}
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
[torque] Improve formatting in format-torque Issues/problems addressed: - Fix line-wrapping and indenting for long declarations including strings, e.g. generates and constexpr clauses. - Implement proper formatting for typeswitch statements - Fix formatting of operator declarations - Fix formatting of constexpr if-clauses (the constexpr is now included on the same line as the if and it doesn't mess up the formatting that - Fix formatting of label declarations on callables, the "label" keyword now always starts a new line with indentation. - Remove space after identifier name in generic parameter declarations, e.g. "<a : T>" is now "<a: T>" which is consistent with type specification formatting elsewhere. - Indent "otherwise" clauses that have been pushed to the next line. Also ran the formatter over all existing .tq files. Bug: v8:7793 Change-Id: I5adbb2ffa3d573deed062f9a5c1da57348c8fc71 Reviewed-on: https://chromium-review.googlesource.com/1238580 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56158}
2018-09-24 09:28:48 +00:00
macro ToIndex(input: Object, context: Context): Number
labels RangeError {
[dataview] Fix too tight TNode type in DataView getters This CL fixes a bug found by Clusterfuzz, in which the functions LoadDataViewByteOffset and -ByteLength incorrectly had a return type of TNode<Smi> instead of TNode<Number>. This caused a CAST() call to fail when the requested byte offset or byte length did not fit inside a Smi, i.e. when the underlying ArrayBuffer of the DataView had a length longer than 2^30 on 32-bit platforms. The CL also includes a new test in mjsunit to test against this. Bug: chromium:869313 Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70 Reviewed-on: https://chromium-review.googlesource.com/1158582 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54900}
2018-08-02 14:41:58 +00:00
if (input == Undefined) {
return 0;
}
let value: Number = ToInteger_Inline(context, input, kTruncateMinusZero);
if (value < 0 || value > kMaxSafeInteger) {
goto RangeError;
}
return value;
}
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
[torque] Implement transient types and checking In the process implement TopType to express undefined values and transient types after they no longer are valid, as well as checks to make sure that transtioning callables are transitively marked to express if they or their call chain modify transient types. Bug: v8:7793 Change-Id: Idb237e878d3a511a4f460b6510ffd4876593951d Reviewed-on: https://chromium-review.googlesource.com/c/1297963 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57052}
2018-10-27 11:56:57 +00:00
transitioning macro GetLengthProperty(implicit context: Context)(o: Object):
Number {
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
try {
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
typeswitch (o) {
case (a: JSArray): {
return a.length;
}
case (a: JSArgumentsObjectWithLength): {
Reland: [builtins] Implement Array.prototype.slice in Torque In the process: - add volatile types for FastJSArray and remove the length_fast accessor from JSArray with the application of more rigorous typing. - add micro benchmarks for testing all the interesting slice cases Also update a few assorted places in .tq code to make them more idiomatic. The original version of this patch had an overly agressive assert that has been loosened. TBR=jgruber@chromium.org Change-Id: I56870862f4b124d1b38372daa326182a526c874c Reviewed-on: https://chromium-review.googlesource.com/c/1291375 Reviewed-by: Daniel Clifford <danno@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#56829}
2018-10-19 16:00:14 +00:00
goto ToLength(a.length);
[torque] Implement implicit parameters The implicit parameter syntax adds a second parameter list before the explicit parameter list when declaring macros, builtins and runtime functions: extern macro MyMacro(implicit a: Smi)(b: Oddball); when calling the macro, only the formal parameters can be provided at the call site. The implicit parameters are implicitly looked-up by name in the scope of the call and prepended to the explicit parameter list. The values that are found by name for each implicit parameter must be castable the corresponding implicit parameter type: MyMacro(Null); // Error, a is not defined ... const a: Smi = 0; MyMacro(Null); // OK ... const a: Object = 0; MyMacro(Null); // Error, a has wrong type For external macros, builtins and runtime functions, the formal parameter list expected on the C++ side is the concatenation of the implicit and explicit parameter lists. As a drive-by: fix the formatting of typeswitch statements in the the presence of deferred-marked blocks and funky white space. Bug: v8:7793 Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4 Reviewed-on: https://chromium-review.googlesource.com/c/1270996 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56555}
2018-10-11 08:52:36 +00:00
}
case (Object): deferred {
goto ToLength(GetProperty(o, kLengthString));
}
}
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
}
[torque] Allow atomarStatements in otherwise statements In the process: - Convert TryLabelStatements into TryLabelExpressions - Change TryLabelExpressions to support only single label blocks and de-sugar try/labels into nested try/label statements. This allows the code in a label block to goto subsequent labels in the same try/label statement. - Make otherwise expressions either take IdentifierExpressions which get converted into simple label names OR atomarStatements, which make useful non-label operations, like 'break' and 'continue', useful together with otherwise. Non-label otherwise statements get de-sugared into try/label blocks. Bug: v8:7793 Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db Reviewed-on: https://chromium-review.googlesource.com/c/1266997 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56447}
2018-10-08 13:50:46 +00:00
label ToLength(length: Object) deferred {
Clean up common argument objects that share length property 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}
2018-09-28 11:28:29 +00:00
return ToLength_Inline(context, length);
}
}
[builtins] Port Array.p.join to Torque. This also includes ports of Array.p.toString and Array.p.toLocaleString. Many parts of the old JS implementation are preserved, because TypedArray.p.join still relies on it. These will be removed once TypedArray.p.join is ported to Torque. To simplify implementation, special handling of extremely sparse arrays has been removed. Performance improvements vary by array size, elements, and sparse-ness. Some quick numbers and graphs are here: https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ia4069a068403ce36676c37401d349aefc976b045 Reviewed-on: https://chromium-review.googlesource.com/c/1196693 Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#56699}
2018-10-16 12:52:25 +00:00
extern macro NumberToString(Number): String;
extern macro HasOnlyOneByteChars(InstanceType): bool;
extern macro AllocateSeqOneByteString(implicit context: Context)(uint32):
String;
extern macro AllocateSeqTwoByteString(implicit context: Context)(uint32):
String;
extern macro TryIntPtrAdd(intptr, intptr): intptr
labels IfOverflow;
extern builtin ObjectToString(Context, Object): Object;
Reland "[builtins] Fix Array.p.join length overflow and invalid string length handling" This is a reland of ec969ea3b18eeba7d9deea09142da8b6d882a4af Temporarily removes high memory usage test. Original change's description: > [builtins] Fix Array.p.join length overflow and invalid string length handling > > - Fixes and simplify allocating the temporary fixed array for ToString-ed elements. > - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail. > - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback. > > - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack. > > Bug: chromium:897404 > Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591 > Reviewed-on: https://chromium-review.googlesource.com/c/1293070 > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56907} Bug: chromium:897404 Change-Id: I4995893f6f9724b26c231d05619ad65dbccc7223 Reviewed-on: https://chromium-review.googlesource.com/c/1297675 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> Cr-Commit-Position: refs/heads/master@{#56946}
2018-10-24 12:25:09 +00:00
extern builtin StringRepeat(Context, String, Number): String;
Add a Torque module exposing iterators 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}
2018-10-31 14:59:13 +00:00
[builtins] Implement LoadKeyValuePair in Torque Change-Id: I0652a75f6d1f6abfb40ba9bf35afeadfd4533336 Reviewed-on: https://chromium-review.googlesource.com/c/1328801 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57531}
2018-11-15 08:55:27 +00:00
struct KeyValuePair {
key: Object;
value: Object;
}
[torque] Simplify and cleanup Cast and UnsafeCast 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}
2018-11-26 15:14:25 +00:00
// Macro definitions for compatibility that expose functionality to the CSA
// using "legacy" APIs. In Torque code, these should not be used.
macro IsFastJSArray(o: Object, context: Context): bool {
try {
// Long-term, it's likely not a good idea to have this slow-path test here,
// since it fundamentally breaks the type system.
GotoIfForceSlowPath() otherwise ForceSlow;
}
label ForceSlow {
return false;
}
return Is<FastJSArray>(o);
}
macro BranchIfFastJSArray(o: Object, context: Context): never
labels True, False {
// Long-term, it's likely not a good idea to have this slow-path test here,
// since it fundamentally breaks the type system.
GotoIfForceSlowPath() otherwise False;
BranchIf<FastJSArray>(o) otherwise True, False;
}
macro BranchIfNotFastJSArray(o: Object, context: Context): never
labels True, False {
BranchIfNot<FastJSArray>(o) otherwise True, False;
}
macro BranchIfFastJSArrayForCopy(o: Object, context: Context): never
labels True, False {
// Long-term, it's likely not a good idea to have this slow-path test here,
// since it fundamentally breaks the type system.
GotoIfForceSlowPath() otherwise False;
BranchIf<FastJSArrayForCopy>(o) otherwise True, False;
}
macro IsFastJSArrayWithNoCustomIteration(context: Context, o: Object): bool {
return Is<FastJSArrayWithNoCustomIteration>(o);
}
Reference in New Issue Copy Permalink