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

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

454 lines
20 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.
[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: 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 void generates 'void';
type never generates 'void';
[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 Tagged generates 'TNode<Object>';
type Smi extends Tagged generates 'TNode<Smi>';
type HeapObject extends Tagged generates 'TNode<HeapObject>';
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
type Object = Smi|HeapObject;
[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 int32 generates 'TNode<Int32T>' constexpr 'int32_t';
[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
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 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';
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
type int31 extends int32 generates 'TNode<Int32T>' constexpr 'int32_t';
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>';
[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>';
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>';
type String extends HeapObject generates 'TNode<String>';
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>';
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
type Number = Smi|HeapNumber;
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 Boolean extends Oddball generates 'TNode<Oddball>';
[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>';
type JSArray extends JSObject generates 'TNode<JSArray>';
[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>';
type JSBoundFunction extends JSObject generates 'TNode<JSBoundFunction>';
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
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>';
type FixedDoubleArray extends FixedArrayBase generates
'TNode<FixedDoubleArray>';
[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 FixedTypedArrayBase extends FixedArrayBase generates
'TNode<FixedTypedArrayBase>';
type FixedTypedArray extends FixedTypedArrayBase generates
'TNode<FixedTypedArray>';
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
type JSArrayBuffer extends JSObject generates 'TNode<JSArrayBuffer>';
type JSArrayBufferView extends JSObject generates 'TNode<JSArrayBufferView>';
[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
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';
type LanguageMode generates 'TNode<Smi>' constexpr 'LanguageMode';
type ExtractFixedArrayFlags generates
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'TNode<Smi>' constexpr 'ExtractFixedArrayFlags';
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
type ParameterMode generates 'TNode<Int32T>' constexpr 'ParameterMode';
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
type RootListIndex generates 'TNode<Int32T>' constexpr 'Heap::RootListIndex';
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
type MessageTemplate constexpr 'MessageTemplate';
type HasPropertyLookupMode constexpr 'HasPropertyLookupMode';
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
[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
const NO_ELEMENTS: constexpr ElementsKind = 'NO_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
const PACKED_SMI_ELEMENTS: constexpr ElementsKind = 'PACKED_SMI_ELEMENTS';
const HOLEY_SMI_ELEMENTS: constexpr ElementsKind = 'HOLEY_SMI_ELEMENTS';
const PACKED_ELEMENTS: constexpr ElementsKind = 'PACKED_ELEMENTS';
const HOLEY_ELEMENTS: constexpr ElementsKind = 'HOLEY_ELEMENTS';
const PACKED_DOUBLE_ELEMENTS: constexpr ElementsKind = 'PACKED_DOUBLE_ELEMENTS';
const HOLEY_DOUBLE_ELEMENTS: constexpr ElementsKind = 'HOLEY_DOUBLE_ELEMENTS';
const UINT8_ELEMENTS: constexpr ElementsKind = 'UINT8_ELEMENTS';
const INT8_ELEMENTS: constexpr ElementsKind = 'INT8_ELEMENTS';
const UINT16_ELEMENTS: constexpr ElementsKind = 'UINT16_ELEMENTS';
const INT16_ELEMENTS: constexpr ElementsKind = 'INT16_ELEMENTS';
const UINT32_ELEMENTS: constexpr ElementsKind = 'UINT32_ELEMENTS';
const INT32_ELEMENTS: constexpr ElementsKind = 'INT32_ELEMENTS';
const FLOAT32_ELEMENTS: constexpr ElementsKind = 'FLOAT32_ELEMENTS';
const FLOAT64_ELEMENTS: constexpr ElementsKind = 'FLOAT64_ELEMENTS';
const UINT8_CLAMPED_ELEMENTS: constexpr ElementsKind = 'UINT8_CLAMPED_ELEMENTS';
const BIGUINT64_ELEMENTS: constexpr ElementsKind = 'BIGUINT64_ELEMENTS';
const BIGINT64_ELEMENTS: constexpr ElementsKind = 'BIGINT64_ELEMENTS';
[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]: 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
const kAllFixedArrays: constexpr ExtractFixedArrayFlags =
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
'ExtractFixedArrayFlag::kAllFixedArrays';
const kCOWMap: Map = 'LoadRoot(Heap::kFixedCOWArrayMapRootIndex)';
const kEmptyFixedArray: FixedArrayBase =
'UncheckedCast<FixedArrayBase>(LoadRoot(Heap::kEmptyFixedArrayRootIndex))';
[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
const kInvalidArrayLength: constexpr MessageTemplate =
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
'MessageTemplate::kInvalidArrayLength';
[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
const kCalledNonCallable: constexpr MessageTemplate =
[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
'MessageTemplate::kCalledNonCallable';
[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
const kCalledOnNullOrUndefined: constexpr MessageTemplate =
[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
'MessageTemplate::kCalledOnNullOrUndefined';
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
const kHasProperty: constexpr HasPropertyLookupMode = 'kHasProperty';
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
const kMaxSafeInteger: constexpr float64 = 'kMaxSafeInteger';
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
const kNotTypedArray: constexpr MessageTemplate =
'MessageTemplate::kNotTypedArray';
const kDetachedOperation: constexpr MessageTemplate =
[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
'MessageTemplate::kDetachedOperation';
[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
const kBadSortComparisonFunction: constexpr MessageTemplate =
[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
'MessageTemplate::kBadSortComparisonFunction';
[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
const kIncompatibleMethodReceiver: constexpr MessageTemplate =
[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
'MessageTemplate::kIncompatibleMethodReceiver';
[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
const kInvalidDataViewAccessorOffset: constexpr MessageTemplate =
'MessageTemplate::kInvalidDataViewAccessorOffset';
[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] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
const Hole: Oddball = 'TheHoleConstant()';
const Null: Oddball = 'NullConstant()';
const Undefined: Oddball = 'UndefinedConstant()';
const True: Boolean = 'TrueConstant()';
const False: Boolean = 'FalseConstant()';
const true: constexpr bool = 'true';
const false: constexpr bool = 'false';
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] Renamed LanguageMode constants in torque R=tebbi@chromium.org Change-Id: Id524c8239f99fc26ac5cd19cbdea39dba62f2c3f Reviewed-on: https://chromium-review.googlesource.com/1071650 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53331}
2018-05-24 11:19:32 +00:00
const kStrict: constexpr LanguageMode = 'LanguageMode::kStrict';
const kSloppy: constexpr LanguageMode = 'LanguageMode::kSloppy';
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] 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
const SMI_PARAMETERS: constexpr ParameterMode = 'SMI_PARAMETERS';
const INTPTR_PARAMETERS: constexpr ParameterMode = 'INTPTR_PARAMETERS';
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;
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;
extern macro GetProperty(Context, Object, Object): 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
extern macro HasProperty(
HeapObject, Object, Context, constexpr HasPropertyLookupMode): Oddball;
extern macro ThrowRangeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate, Object): 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
extern macro ArraySpeciesCreate(Context, Object, Number): Object;
[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 EnsureArrayPushable(Map): ElementsKind labels Bailout;
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;
[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
extern runtime CreateDataProperty(Context, Object, Object, Object);
extern runtime SetProperty(Context, Object, Object, Object, LanguageMode);
extern runtime DeleteProperty(Context, Object, Object, LanguageMode);
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 LoadRoot(constexpr RootListIndex): Object;
extern macro StoreRoot(constexpr RootListIndex, Object): Object;
extern macro LoadAndUntagToWord32Root(constexpr RootListIndex): int32;
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;
extern runtime SmiLexicographicCompare(Context, Object, 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
[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 Word32Equal(int32, int32): bool;
extern operator '!=' macro Word32NotEqual(int32, int32): bool;
extern operator '<' macro Int32LessThan(int32, int32): bool;
extern operator '>' macro Int32GreaterThan(int32, int32): bool;
extern operator '<=' macro Int32LessThanOrEqual(int32, int32): bool;
extern operator '>=' macro Int32GreaterThanOrEqual(int32, int32): 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;
extern macro IsFastElementsKind(constexpr ElementsKind): 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 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;
extern operator '!=' macro WordNotEqual(intptr, intptr): bool;
extern operator '<' macro IntPtrLessThan(intptr, intptr): bool;
extern operator '>' macro IntPtrGreaterThan(intptr, intptr): bool;
extern operator '<=' macro IntPtrLessThanOrEqual(intptr, intptr): bool;
extern operator '>=' macro IntPtrGreaterThanOrEqual(intptr, 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]: 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;
[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: 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
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'<' macro BranchIfNumberLessThan(Number, Number): never 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
extern operator
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'<=' macro BranchIfNumberLessThanOrEqual(Number, Number): never 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
extern operator
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'>' macro BranchIfNumberGreaterThan(Number, Number): never 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
extern operator '>=' macro BranchIfNumberGreaterThanOrEqual(Number, Number):
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
never 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;
[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 SmiShr(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;
[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 operator '>>>' macro WordShr(intptr, intptr): 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
[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;
extern operator '*' macro Int32Mul(int32, int32): int32;
extern operator '%' macro Int32Mod(int32, int32): int32;
extern operator '&' macro Word32And(int32, int32): int32;
extern operator '<<' macro Word32Shl(int32, int32): int32;
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;
extern operator 'min' macro NumberMin(Number, Number): Number;
extern operator 'max' macro NumberMax(Number, Number): Number;
[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;
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;
extern operator '.map=' macro StoreMap(HeapObject, Map);
[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
[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
'.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;
extern operator
[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
'[]' 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
[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 'is<Smi>' macro TaggedIsSmi(Object): bool;
extern operator 'isnt<Smi>' 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;
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 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
extern macro TaggedToJSDataView(Object): JSDataView labels CastError;
extern macro TaggedToHeapObject(Object): HeapObject labels CastError;
extern macro TaggedToSmi(Object): Smi labels CastError;
extern macro TaggedToJSArray(Object): JSArray labels CastError;
extern macro TaggedToCallable(Object): Callable labels CastError;
extern macro ConvertFixedArrayBaseToFixedArray(
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
FixedArrayBase): FixedArray labels 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
extern macro ConvertFixedArrayBaseToFixedDoubleArray(
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
FixedArrayBase): FixedDoubleArray labels 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
extern macro TaggedToNumber(Object): Number labels CastError;
macro cast<A : type>(o: Object): A labels CastError;
cast<Number>(o: Object): Number labels CastError {
return TaggedToNumber(o) otherwise CastError;
}
cast<HeapObject>(o: Object): HeapObject labels CastError {
return TaggedToHeapObject(o) otherwise CastError;
}
cast<Smi>(o: Object): Smi labels CastError {
return TaggedToSmi(o) otherwise CastError;
}
cast<JSDataView>(o: Object): JSDataView labels CastError {
return TaggedToJSDataView(o) otherwise CastError;
}
cast<Callable>(o: Object): Callable labels CastError {
return TaggedToCallable(o) otherwise CastError;
}
cast<JSArray>(o: Object): JSArray labels CastError {
return TaggedToJSArray(o) otherwise CastError;
}
macro cast<A : type>(o: FixedArrayBase): A labels CastError;
cast<FixedArray>(o: FixedArrayBase): FixedArray labels CastError {
return ConvertFixedArrayBaseToFixedArray(o) otherwise CastError;
}
cast<FixedDoubleArray>(o: FixedArrayBase): FixedDoubleArray labels CastError {
return ConvertFixedArrayBaseToFixedDoubleArray(o) otherwise CastError;
}
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: 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 implicit operator
[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
'convert<>' macro NumberConstant(constexpr float64): Number;
[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 implicit operator
'convert<>' macro IntPtrConstant(constexpr int31): intptr;
extern implicit operator
'convert<>' macro Int32Constant(constexpr int31): int32;
[torque] Fix int32 literals This CL changes the behaviour of number literals. Large integer literals (bigger than Smi, but fit into int32) should have type "constexpr int32" instead of "constexpr float64". R=tebbi@chromium.org Change-Id: I3a83c617c7d257451d299670c891fac5b21d045c Reviewed-on: https://chromium-review.googlesource.com/1084991 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53522}
2018-06-05 11:54:38 +00:00
extern implicit operator
'convert<>' macro Int32Constant(constexpr int32): int32;
[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 implicit operator 'convert<>' macro SmiConstant(constexpr int31): Smi;
extern implicit operator
'convert<>' macro NumberConstant(constexpr int31): Number;
extern implicit operator 'convert<>' macro BoolConstant(constexpr bool): bool;
extern implicit operator 'convert<>' macro LanguageModeConstant(
constexpr LanguageMode): LanguageMode;
[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
extern operator
'convert<>' macro Int32Constant(constexpr ElementsKind): ElementsKind;
[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 implicit operator 'convert<>' macro SmiFromInt32(ElementsKind): 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 'convert<>' macro ChangeInt32ToTagged(int32): Number;
[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 'convert<>' macro ChangeUint32ToTagged(uint32): Number;
extern operator 'convert<>' macro UncheckedCastInt32ToUint32(int32): uint32;
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 'convert<>' macro TruncateWordToWord32(intptr): int32;
extern operator 'convert<>' macro SmiTag(intptr): Smi;
[typedarray] Change Torque sort implementation This CL changes how TypedArray.p.sort is implemented in Torque, mainly to address the binary memory size of the builtin. With this CL the memory comes down from 53611 to 4215 (as reported by --print-builtin-size on a x64.release build). With the following performance impact on the relevant benchmarks: Benchmark Original (JS) Torque (initial) This CL IntTypes 83.9 263.7 202.3 BigIntTypes 32.1 54.6 47.2 FloatTypes 99.3 138.7 109.3 This is achieved by pushing the Load/Store dispatch based on the elements kind into separate builtins that are executed for each load/store. This results in only one version of the sorting algorithm instead of one version per elements kind. R=jgruber@chromium.org Bug: chromium:837282 Change-Id: I7fe2da3cbfd01531d070128126a0d56d3dd6bdcc Reviewed-on: https://chromium-review.googlesource.com/1033744 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52937}
2018-05-03 07:35:25 +00:00
extern operator 'convert<>' macro SmiFromInt32(int32): 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 'convert<>' macro SmiUntag(Smi): intptr;
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 operator 'convert<>' macro SmiToInt32(Smi): int32;
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 operator 'convert<>' macro LoadHeapNumberValue(HeapNumber): float64;
[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
extern operator 'convert<>' macro ChangeFloat32ToFloat64(float32): float64;
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 operator 'convert<>' macro ChangeNumberToFloat64(Number): 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
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
extern macro BranchIfFastJSArray(Object, Context): never labels Taken, NotTaken;
extern macro BranchIfNotFastJSArray(Object, Context): never 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 macro IsPrototypeInitialArrayPrototype(Context, Map): bool;
extern macro IsNoElementsProtectorCellInvalid(): bool;
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
[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 operator
[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
'.buffer' macro 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
extern operator '.data_ptr' macro LoadDataPtr(JSTypedArray): RawPtr;
[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;
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
[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 operator '.length' macro LoadTypedArrayLength(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;
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 operator '.length_fast' macro LoadFastJSArrayLength(JSArray): 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;
extern operator '[]' macro LoadFixedArrayElement(FixedArray, intptr): Object;
extern operator '[]' macro LoadFixedArrayElement(FixedArray, Smi): Object;
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 operator
'[]' macro LoadFixedArrayElementInt(FixedArray, constexpr int31): 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
extern operator
'[]=' macro StoreFixedArrayElement(FixedArray, intptr, Object): void;
extern operator
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
'[]=' macro StoreFixedArrayElementInt(
FixedArray, constexpr int31, Object): void;
extern operator
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
'[]=' macro StoreFixedArrayElementSmi(FixedArray, Smi, Object): 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
extern macro LoadFixedDoubleArrayElement(FixedDoubleArray, Smi): float64;
extern macro Float64SilenceNaN(float64): float64;
extern macro StoreFixedDoubleArrayElement(
FixedDoubleArray, Object, float64, constexpr ParameterMode);
macro StoreFixedDoubleArrayElementWithSmiIndex(
array: FixedDoubleArray, index: Smi, value: float64) {
StoreFixedDoubleArrayElement(array, index, value, SMI_PARAMETERS);
}
[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;
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
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 AllocateFixedArray(constexpr ElementsKind, intptr): 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
extern macro IsElementsKindGreaterThan(
ElementsKind, constexpr ElementsKind): bool;
extern macro LoadDoubleWithHoleCheck(FixedDoubleArray, Smi): float64
labels IfHole;
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 Call(Context, Callable, Object, ...): Object;
extern macro ExtractFixedArray(
[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
FixedArray, Smi, Smi, Smi, 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;
[torque] allow templates without body Change-Id: Ie61c8fa51c7c13ab74c4c97ed6803be7f879a549 Reviewed-on: https://chromium-review.googlesource.com/1069088 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#53293}
2018-05-22 21:18:42 +00:00
macro LoadElementNoHole<T : type>(a: JSArray, index: Smi): Object 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
LoadElementNoHole<FixedArray>(a: JSArray, index: Smi): Object
labels IfHole {
try {
let elements: FixedArray =
cast<FixedArray>(a.elements) otherwise Unexpected;
let e: Object = elements[index];
if (e == Hole) {
goto IfHole;
}
return e;
}
label Unexpected {
unreachable;
}
}
LoadElementNoHole<FixedDoubleArray>(a: JSArray, index: Smi): Object
labels IfHole {
try {
let elements: FixedDoubleArray =
cast<FixedDoubleArray>(a.elements) otherwise Unexpected;
let e: float64 = LoadDoubleWithHoleCheck(elements, index) otherwise IfHole;
return AllocateHeapNumberWithValue(e);
}
label Unexpected {
unreachable;
}
}
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
macro HasPropertyObject(
[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
o: Object, p: Object, c: Context,
f: constexpr HasPropertyLookupMode): Oddball {
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
try {
[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
return HasProperty((cast<HeapObject>(o) otherwise CastError), p, c, f);
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
}
label CastError {
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
return False;
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
}
}
[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 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;
[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;
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 NumberIsNaN(Number): bool;
Reference in New Issue Copy Permalink