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

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

702 lines
28 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;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
type int32 generates 'TNode<Int32T>' constexpr 'int32_t';
type uint32 generates 'TNode<Uint32T>' constexpr 'uint32_t';
[dataview] Move DataView floating point getters to Torque This CL moves the DataViewGetFloat32 and DataViewGetFloat64 getters from runtime to Torque. Change-Id: Ic85ec7bcb4e48f679c24e28121b7c543454e7cde Reviewed-on: https://chromium-review.googlesource.com/1088919 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53606}
2018-06-07 08:02:33 +00:00
type int64 generates 'TNode<Int64T>' constexpr 'int64_t';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type intptr generates 'TNode<IntPtrT>' constexpr 'intptr_t';
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
type uintptr generates 'TNode<UintPtrT>' constexpr 'uintptr_t';
[dataview] Move DataView floating point getters to Torque This CL moves the DataViewGetFloat32 and DataViewGetFloat64 getters from runtime to Torque. Change-Id: Ic85ec7bcb4e48f679c24e28121b7c543454e7cde Reviewed-on: https://chromium-review.googlesource.com/1088919 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53606}
2018-06-07 08:02:33 +00:00
type float32 generates 'TNode<Float32T>' constexpr 'float';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type float64 generates 'TNode<Float64T>' constexpr 'double';
type bool generates 'TNode<BoolT>' constexpr 'bool';
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
type string constexpr 'const char*';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
type int31 extends int32 generates 'TNode<Int32T>' constexpr 'int31_t';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type RawPtr generates 'TNode<RawPtrT>' constexpr 'void*';
[torque] implement function pointers to builtins This CL adds the new type expression builtin(Context, ArgType1, ...) => ReturnType and allows to use Torque-defined builtins as values of this type, as well as calling values of this type. The new function pointer types are subtypes of Code. Change-Id: Ib7ba3ce6ef7a8591a4c79230dd189fd25698d5b9 Reviewed-on: https://chromium-review.googlesource.com/1060056 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53217}
2018-05-16 14:00:35 +00:00
type AbstractCode extends HeapObject generates 'TNode<AbstractCode>';
type Code extends AbstractCode generates 'TNode<Code>';
[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>';
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
type String extends HeapObject generates 'TNode<String>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type Oddball extends HeapObject generates 'TNode<Oddball>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type HeapNumber extends HeapObject generates 'TNode<HeapNumber>';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
type Number = Smi|HeapNumber;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
type BigInt extends HeapObject generates 'TNode<BigInt>';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
type Numeric = Number|BigInt;
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>';
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
type NumberDictionary extends HeapObject generates 'TNode<NumberDictionary>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[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
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const NO_ELEMENTS: constexpr ElementsKind generates 'NO_ELEMENTS';
const PACKED_SMI_ELEMENTS: constexpr ElementsKind generates
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
'PACKED_SMI_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const HOLEY_SMI_ELEMENTS: constexpr ElementsKind generates 'HOLEY_SMI_ELEMENTS';
const PACKED_ELEMENTS: constexpr ElementsKind generates 'PACKED_ELEMENTS';
const HOLEY_ELEMENTS: constexpr ElementsKind generates 'HOLEY_ELEMENTS';
const PACKED_DOUBLE_ELEMENTS: constexpr ElementsKind generates
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
'PACKED_DOUBLE_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const HOLEY_DOUBLE_ELEMENTS: constexpr ElementsKind generates
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
'HOLEY_DOUBLE_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const DICTIONARY_ELEMENTS: constexpr ElementsKind generates
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
'DICTIONARY_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const UINT8_ELEMENTS: constexpr ElementsKind generates 'UINT8_ELEMENTS';
const INT8_ELEMENTS: constexpr ElementsKind generates 'INT8_ELEMENTS';
const UINT16_ELEMENTS: constexpr ElementsKind generates 'UINT16_ELEMENTS';
const INT16_ELEMENTS: constexpr ElementsKind generates 'INT16_ELEMENTS';
const UINT32_ELEMENTS: constexpr ElementsKind generates 'UINT32_ELEMENTS';
const INT32_ELEMENTS: constexpr ElementsKind generates 'INT32_ELEMENTS';
const FLOAT32_ELEMENTS: constexpr ElementsKind generates 'FLOAT32_ELEMENTS';
const FLOAT64_ELEMENTS: constexpr ElementsKind generates 'FLOAT64_ELEMENTS';
const UINT8_CLAMPED_ELEMENTS: constexpr ElementsKind generates
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
'UINT8_CLAMPED_ELEMENTS';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const BIGUINT64_ELEMENTS: constexpr ElementsKind generates 'BIGUINT64_ELEMENTS';
const BIGINT64_ELEMENTS: constexpr ElementsKind generates 'BIGINT64_ELEMENTS';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
[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] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const kAllFixedArrays: constexpr ExtractFixedArrayFlags generates
'ExtractFixedArrayFlag::kAllFixedArrays';
const kCOWMap: Map generates 'LoadRoot(Heap::kFixedCOWArrayMapRootIndex)';
const kEmptyFixedArray: FixedArrayBase generates
'UncheckedCast<FixedArrayBase>(LoadRoot(Heap::kEmptyFixedArrayRootIndex))';
const kInvalidArrayLength: constexpr MessageTemplate generates
'MessageTemplate::kInvalidArrayLength';
const kCalledNonCallable: constexpr MessageTemplate generates
'MessageTemplate::kCalledNonCallable';
const kCalledOnNullOrUndefined: constexpr MessageTemplate generates
'MessageTemplate::kCalledOnNullOrUndefined';
const kHasProperty: constexpr HasPropertyLookupMode generates 'kHasProperty';
const kMaxSafeInteger: constexpr float64 generates 'kMaxSafeInteger';
const kNotTypedArray: constexpr MessageTemplate generates
'MessageTemplate::kNotTypedArray';
const kDetachedOperation: constexpr MessageTemplate generates
'MessageTemplate::kDetachedOperation';
const kBadSortComparisonFunction: constexpr MessageTemplate generates
'MessageTemplate::kBadSortComparisonFunction';
const kIncompatibleMethodReceiver: constexpr MessageTemplate generates
'MessageTemplate::kIncompatibleMethodReceiver';
const kInvalidDataViewAccessorOffset: constexpr MessageTemplate generates
'MessageTemplate::kInvalidDataViewAccessorOffset';
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
const kStrictReadOnlyProperty: constexpr MessageTemplate generates
'MessageTemplate::kStrictReadOnlyProperty';
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
const Hole: Oddball generates 'TheHoleConstant()';
const Null: Oddball generates 'NullConstant()';
const Undefined: Oddball generates 'UndefinedConstant()';
const True: Boolean generates 'TrueConstant()';
const False: Boolean generates 'FalseConstant()';
const true: constexpr bool generates 'true';
const false: constexpr bool generates 'false';
const kStrict: constexpr LanguageMode generates 'LanguageMode::kStrict';
const kSloppy: constexpr LanguageMode generates 'LanguageMode::kSloppy';
const SMI_PARAMETERS: constexpr ParameterMode generates 'SMI_PARAMETERS';
const INTPTR_PARAMETERS: constexpr ParameterMode generates 'INTPTR_PARAMETERS';
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Is64(): constexpr bool;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro Print(constexpr string);
extern macro Print(constexpr string, Object);
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;
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
extern macro ThrowTypeError(Context, constexpr MessageTemplate, Object, Object,
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 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;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern operator '==' macro ElementsKindEqual(ElementsKind, ElementsKind): bool;
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
extern macro IsFastElementsKind(constexpr ElementsKind): constexpr bool;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro IsDoubleElementsKind(constexpr ElementsKind): constexpr bool;
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro SmiAbove(Smi, Smi): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro WordEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '==' macro WordEqual(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '!=' macro WordNotEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '!=' macro WordNotEqual(uintptr, uintptr): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '<' macro IntPtrLessThan(intptr, intptr): bool;
extern operator '>' macro IntPtrGreaterThan(intptr, intptr): bool;
extern operator '<=' macro IntPtrLessThanOrEqual(intptr, intptr): bool;
extern operator '>=' macro IntPtrGreaterThanOrEqual(intptr, intptr): bool;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '>=' macro UintPtrGreaterThanOrEqual(uintptr, uintptr): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro Float64Equal(float64, float64): bool;
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
extern operator '!=' macro Float64NotEqual(float64, float64): bool;
[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;
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
extern operator '>>>' macro WordShr(uintptr, uintptr): uintptr;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern operator '<<' macro WordShl(intptr, intptr): intptr;
extern operator '&' macro WordAnd(intptr, intptr): intptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '&' macro WordAnd(uintptr, uintptr): uintptr;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
extern operator '+' macro Int32Add(int32, int32): int32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern operator '-' macro Int32Sub(int32, int32): int32;
[dataview] Implement Torque/CSA getters for DataView This CL fully implements the DataView getters for the Uint8, Int8, Uint16, Int16, Uint32 and Int32 types in Torque, and removes the runtime implementation that is not needed anymore. There should be a light but visible performance increase compared to the former runtime implementation. Change-Id: I7d85097fd5953b9629f3ac6bed93b068889712b2 Reviewed-on: https://chromium-review.googlesource.com/1078349 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53553}
2018-06-06 12:30:08 +00:00
extern operator '*' macro Int32Mul(int32, int32): int32;
extern operator '%' macro Int32Mod(int32, int32): int32;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '&' macro Word32And(int32, int32): int32;
extern operator '&' macro Word32And(uint32, uint32): uint32;
[torque] Add constexpr int31 equality operator This CL adds a constexpr int31 == operator that returns a constexpr bool value. It also fixes a bug that this introduces because branch generation for ternary operators incorrectly assumed that the condition value was bool, whereas it can also be constexpr bool now. Change-Id: Ie7d3497c9d1112c121b4a29561fe065b5bf01fb6 Reviewed-on: https://chromium-review.googlesource.com/1106343 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53867}
2018-06-19 15:58:56 +00:00
extern operator '==' macro
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
ConstexprInt31Equal(constexpr int31, constexpr int31): constexpr bool;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern operator '==' macro Word32Equal(int32, int32): bool;
extern operator '==' macro Word32Equal(uint32, uint32): bool;
extern operator '!=' macro Word32NotEqual(int32, int32): bool;
extern operator '!=' macro Word32NotEqual(uint32, uint32): bool;
extern operator '>>>' macro Word32Shr(uint32, uint32): uint32;
extern operator '<<' macro Word32Shl(int32, int32): int32;
extern operator '<<' macro Word32Shl(uint32, uint32): uint32;
extern operator '|' macro Word32Or(int32, int32): int32;
extern operator '|' macro Word32Or(uint32, uint32): uint32;
[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
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;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro ConvertFixedArrayBaseToFixedArray(FixedArrayBase):
FixedArray labels CastError;
extern macro ConvertFixedArrayBaseToFixedDoubleArray(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;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro cast<A : type>(o: Object): A 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
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;
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro cast<A : type>(o: FixedArrayBase): A 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
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] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro ChangeInt32ToTagged(int32): Number;
extern macro ChangeUint32ToTagged(uint32): Number;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Unsigned(int32): uint32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Unsigned(intptr): uintptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Unsigned(RawPtr): uintptr;
extern macro Signed(uint32): int32;
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
extern macro Signed(uintptr): intptr;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro Signed(RawPtr): intptr;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro TruncateIntPtrToInt32(intptr): int32;
extern macro SmiTag(intptr): Smi;
extern macro SmiFromInt32(int32): Smi;
extern macro SmiUntag(Smi): intptr;
extern macro SmiToInt32(Smi): int32;
extern macro LoadHeapNumberValue(HeapNumber): float64;
extern macro ChangeFloat32ToFloat64(float32): float64;
extern macro ChangeNumberToFloat64(Number): float64;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro ChangeInt32ToIntPtr(int32): intptr; // Sign-extends.
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
extern macro ChangeUint32ToWord(uint32): uintptr; // Doesn't sign-extend.
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro NumberConstant(constexpr float64): Number;
extern macro NumberConstant(constexpr int32): Number;
extern macro IntPtrConstant(constexpr int31): intptr;
extern macro IntPtrConstant(constexpr int32): intptr;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro Int32Constant(constexpr int31): int31;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro Int32Constant(constexpr int32): int32;
[dataview][cleanup] Encapsulate BigInt allocation logic in data-view.tq This CL separates the BigInt allocation code in the DataView BigInt getters from the logic of the getters themselves. This makes the code much easier to read and understand. Change-Id: I9f7ee3fb819f0606dc631bac89e386f6fec43655 Reviewed-on: https://chromium-review.googlesource.com/1107632 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54036}
2018-06-26 13:55:16 +00:00
extern macro Float64Constant(constexpr int31): float64;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro SmiConstant(constexpr int31): Smi;
extern macro BoolConstant(constexpr bool): bool;
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
extern macro StringConstant(constexpr string): String;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro LanguageModeConstant(constexpr LanguageMode): LanguageMode;
extern macro Int32Constant(constexpr ElementsKind): ElementsKind;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(o: constexpr int31): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<intptr>(i: constexpr int31): intptr {
return IntPtrConstant(i);
}
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
from_constexpr<int31>(i: constexpr int31): int31 {
return Int32Constant(i);
}
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<int32>(i: constexpr int31): int32 {
return Int32Constant(i);
}
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
from_constexpr<uint32>(i: constexpr int31): uint32 {
return Unsigned(Int32Constant(i));
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
from_constexpr<uintptr>(i: constexpr int31): uintptr {
return ChangeUint32ToWord(i);
}
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<Smi>(i: constexpr int31): Smi {
return SmiConstant(i);
}
from_constexpr<Number>(i: constexpr int31): Number {
return SmiConstant(i);
}
[dataview][cleanup] Encapsulate BigInt allocation logic in data-view.tq This CL separates the BigInt allocation code in the DataView BigInt getters from the logic of the getters themselves. This makes the code much easier to read and understand. Change-Id: I9f7ee3fb819f0606dc631bac89e386f6fec43655 Reviewed-on: https://chromium-review.googlesource.com/1107632 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54036}
2018-06-26 13:55:16 +00:00
from_constexpr<float64>(i: constexpr int31): float64 {
return Float64Constant(i);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(o: constexpr int32): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<intptr>(i: constexpr int32): intptr {
return IntPtrConstant(i);
}
from_constexpr<int32>(i: constexpr int32): int32 {
[torque]: Fix bug uncovered by Netflix in Canary Bug: chromium:852685 Change-Id: I0bb6cf433a5ea0a91d77048d3eef0d8077b8208e Reviewed-on: https://chromium-review.googlesource.com/1102433 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53766}
2018-06-15 12:30:38 +00:00
return Int32Constant(i);
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
}
from_constexpr<Number>(i: constexpr int32): Number {
return NumberConstant(i);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(o: constexpr float64): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<Number>(f: constexpr float64): Number {
return NumberConstant(f);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(b: constexpr bool): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<bool>(b: constexpr bool): bool {
return BoolConstant(b);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(l: constexpr LanguageMode): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<LanguageMode>(b: constexpr LanguageMode): LanguageMode {
return LanguageModeConstant(b);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro from_constexpr<A : type>(e: constexpr ElementsKind): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
from_constexpr<ElementsKind>(e: constexpr ElementsKind): ElementsKind {
return Int32Constant(e);
}
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
macro from_constexpr<A : type>(s: constexpr string): A;
from_constexpr<String>(s: constexpr string): String {
[torque] Add constexpr String handling to Torque This CL adds a 'constexpr String' type to Torque, which gets compiled to 'const char*'. It makes it easier to pass strings around in Torque files, especially when trying to Print() them. Bug: v8:7793 Change-Id: I2d4feac7012f5401f2b467475f8df086e46ac18a Reviewed-on: https://chromium-review.googlesource.com/1104466 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53814}
2018-06-18 15:50:59 +00:00
return StringConstant(s);
}
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
from_constexpr<Object>(s: constexpr string): Object {
[torque] Add constexpr String handling to Torque This CL adds a 'constexpr String' type to Torque, which gets compiled to 'const char*'. It makes it easier to pass strings around in Torque files, especially when trying to Print() them. Bug: v8:7793 Change-Id: I2d4feac7012f5401f2b467475f8df086e46ac18a Reviewed-on: https://chromium-review.googlesource.com/1104466 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53814}
2018-06-18 15:50:59 +00:00
return StringConstant(s);
}
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
[torque] fix variables, returns and conditionals with constexpr Variables/return values with constexpr type cannot have multiple assignments. We check this now. For conditionals, it is important to always infer a non-constexpr type. This CL adds the ability to map any type (including union types) to be mapped to their non-constexpr variant. Conditionals infer their type as the non-constexpr version of a combination of the two branch types. In addition, this improves subtyping for constexpr types: If A extends B, then constexpr A extends constexpr B. This makes it necessary to clean up "constexpr String", which has nothing to do with tagged values. Bug: v8:7793 Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6 Reviewed-on: https://chromium-review.googlesource.com/1122864 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54167}
2018-07-03 12:02:05 +00:00
macro convert<A : type>(i: constexpr int31): A {
return i;
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(i: int32): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<Number>(i: int32): Number {
return ChangeInt32ToTagged(i);
}
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
convert<intptr>(i: int32): intptr {
return ChangeInt32ToIntPtr(i);
}
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<Smi>(i: int32): Smi {
return SmiFromInt32(i);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(ui: uint32): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<Number>(ui: uint32): Number {
return ChangeUint32ToTagged(ui);
}
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
convert<Smi>(ui: uint32): Smi {
return SmiFromInt32(Signed(ui));
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
convert<uintptr>(ui: uint32): uintptr {
return ChangeUint32ToWord(ui);
[dataview] Move DataView BigInt getters to Torque This CL moves the remaining runtime DataView getters to Torque, namely DataViewGetBigInt64/BigUint64, and removes the associated runtime code that is now unneeded. All of the DataView getters are now implemented in Torque, which brings a nice performance improvement over the former C++ builtin code. Change-Id: I35cf2eabce3c79cc0d3200e7f24dbe0c3e5c2804 Reviewed-on: https://chromium-review.googlesource.com/1092736 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53765}
2018-06-15 12:23:58 +00:00
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(i: intptr): A;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
convert<int32>(i: intptr): int32 {
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
return TruncateIntPtrToInt32(i);
}
convert<Smi>(i: intptr): Smi {
return SmiTag(i);
}
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
macro convert<A : type>(ui: uintptr): A;
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
convert<uint32>(ui: uintptr): uint32 {
return Unsigned(TruncateIntPtrToInt32(Signed(ui)));
[dataview]: Move DataView setters to Torque. This CL completely reimplements the DataView setters in Torque, and removes the former C++ runtime implementation. Change-Id: I66cdd35712e46f3931d6530a4512fa3c8eb3b3bf Reviewed-on: https://chromium-review.googlesource.com/1104162 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53800}
2018-06-18 14:16:44 +00:00
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(s: Smi): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<intptr>(s: Smi): intptr {
return SmiUntag(s);
}
convert<int32>(s: Smi): int32 {
return SmiToInt32(s);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(h: HeapNumber): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<float64>(h: HeapNumber): float64 {
return LoadHeapNumberValue(h);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(n: Number): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<float64>(n: Number): float64 {
return ChangeNumberToFloat64(n);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro convert<A : type>(f: float32): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
convert<float64>(f: float32): float64 {
return ChangeFloat32ToFloat64(f);
}
[dataview] Add fast path for DataView methods This CL adds a fast path for DataView getters and setters when the load or store to be performed is aligned and when the requested endianness matches the platform endianness. In that case, we can just emit the right load/store instruction instead of having to read and write data byte by byte. Change-Id: I10bd95a7fe8d23f695899eb8173bc654fb38fbb0 Reviewed-on: https://chromium-review.googlesource.com/1106168 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54005}
2018-06-25 13:28:25 +00:00
macro convert<A : type>(d: float64): A;
convert<Number>(d: float64): Number {
return AllocateHeapNumberWithValue(d);
}
macro convert<A : type>(r: RawPtr): A;
convert<uintptr>(r: RawPtr): uintptr {
return Unsigned(r);
}
convert<intptr>(r: RawPtr): intptr {
return Signed(r);
}
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro UnsafeCastNumberToHeapNumber(Number): HeapNumber;
extern macro UnsafeCastObjectToFixedArray(Object): FixedArray;
extern macro UnsafeCastObjectToFixedDoubleArray(Object): FixedDoubleArray;
extern macro UnsafeCastObjectToHeapNumber(Object): HeapNumber;
extern macro UnsafeCastObjectToCallable(Object): Callable;
extern macro UnsafeCastObjectToSmi(Object): Smi;
extern macro UnsafeCastObjectToNumber(Object): Number;
extern macro UnsafeCastObjectToHeapObject(Object): HeapObject;
extern macro UnsafeCastObjectToJSArray(Object): JSArray;
extern macro UnsafeCastObjectToFixedTypedArrayBase(Object): FixedTypedArrayBase;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro UnsafeCastObjectToNumberDictionary(Object): NumberDictionary;
extern macro UnsafeCastObjectToJSReceiver(Object): JSReceiver;
extern macro UnsafeCastObjectToJSObject(Object): JSObject;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro unsafe_cast<A : type>(n: Number): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
unsafe_cast<HeapNumber>(n: Number): HeapNumber {
return UnsafeCastNumberToHeapNumber(n);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
macro unsafe_cast<A : type>(o: Object): A;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
unsafe_cast<FixedArray>(o: Object): FixedArray {
return UnsafeCastObjectToFixedArray(o);
}
unsafe_cast<FixedDoubleArray>(o: Object): FixedDoubleArray {
return UnsafeCastObjectToFixedDoubleArray(o);
}
unsafe_cast<HeapNumber>(o: Object): HeapNumber {
return UnsafeCastObjectToHeapNumber(o);
}
unsafe_cast<Callable>(o: Object): Callable {
return UnsafeCastObjectToCallable(o);
}
unsafe_cast<Smi>(o: Object): Smi {
return UnsafeCastObjectToSmi(o);
}
unsafe_cast<Number>(o: Object): Number {
return UnsafeCastObjectToNumber(o);
}
unsafe_cast<HeapObject>(o: Object): HeapObject {
return UnsafeCastObjectToHeapObject(o);
}
unsafe_cast<JSArray>(o: Object): JSArray {
return UnsafeCastObjectToJSArray(o);
}
unsafe_cast<FixedTypedArrayBase>(o: Object): FixedTypedArrayBase {
return UnsafeCastObjectToFixedTypedArrayBase(o);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
unsafe_cast<NumberDictionary>(o: Object): NumberDictionary {
return UnsafeCastObjectToNumberDictionary(o);
}
unsafe_cast<JSReceiver>(o: Object): JSReceiver {
return UnsafeCastObjectToJSReceiver(o);
}
unsafe_cast<JSObject>(o: Object): JSObject {
return UnsafeCastObjectToJSObject(o);
}
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
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
'[]' 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;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern operator '.instance_type' macro LoadMapInstanceType(Map): int32;
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);
}
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro BasicLoadNumberDictionaryElement(NumberDictionary, intptr):
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
Object labels NotData, IfHole;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro BasicStoreNumberDictionaryElement(NumberDictionary, intptr, Object)
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
labels NotData, IfHole, ReadOnly;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsFastElementsKind(ElementsKind): bool;
[torque] Turn implicit converts/unsafe_casts into generics In the process: - Add strict ordering of Types so that name mangling is consistent and build time. Previously, the UnionType stored the union's types in a std::set<const Type*>, which did not have a consistent ordering of the types in the set. - Add a int31 type to enable consistency and correctness of handling of 'constexpr int31' values on the C++ side. - By removing the "implicit" keyword for operators, there is now one less difference between operators and calls, another incremental step in unifying operators and calls. - Enable external (i.e. C++-defined) generic specializations - Add CSA support for checking double ElementsKinds, including tests. - Clean up some constexpr/non-constexpr handling of ElementsKinds. Bug: v8:7793 Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8 Reviewed-on: https://chromium-review.googlesource.com/1091155 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53664}
2018-06-12 11:11:44 +00:00
extern macro IsDoubleElementsKind(ElementsKind): bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsFastSmiOrTaggedElementsKind(ElementsKind): bool;
extern macro IsFastSmiElementsKind(ElementsKind): bool;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro IsHoleyFastElementsKind(ElementsKind): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
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;
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
extern macro IsHeapNumber(HeapObject): bool;
[array] Add fastpath for dictionary elements to Array.p.sort R=cbruni@chromium.org, jgruber@chromium.org Bug: v8:7382 Change-Id: I45f2517afa8ecb3ddb1f77f845e9ce88f69d4eef Reviewed-on: https://chromium-review.googlesource.com/1092500 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53788}
2018-06-18 09:33:18 +00:00
extern macro IsExtensibleMap(Map): bool;
extern macro IsCustomElementsReceiverInstanceType(int32): bool;
[array] Throw TypeError for read-only properties on fast-path This CL changes the NumberDictionary fast-path for Array.p.sort to throw a TypeError when trying to write to a read-only property. Previously, the fast-path simply bailed to the slow-path which could swallow the TypeError by accident. I.e. because the fast-path could leave the array in an inconsistent state that is already sorted. Example: let arr = new Array(10); Object.defineProperty(arr, 0, {value: 2, writable: false}); Object.defineProperty(arr, 2, {value: 1, writable: false}); arr.sort(); The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1} When trying to swap those 2 values, the fast-path will write the 2 at index 1, then try to write the 1 at index 0 and fail, bailing to the slow-path. As the array looks like {0: 2, 1: 2} its already sorted and the TypeError will not be thrown. R=jgruber@chromium.org Bug: v8:7382, v8:7907 Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f Reviewed-on: https://chromium-review.googlesource.com/1122120 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54150}
2018-07-02 14:56:52 +00:00
extern macro Typeof(Object): Object;
Reland "[array] Implement Array.p.sort in Torque" This is a reland of df1676e61619d053e232413e917328cd994dd516 Original change's description: > [array] Implement Array.p.sort in Torque > > This CL implements a generic baseline version and 3 fastpaths, for > various elements kinds, of Array.p.sort in Torque. Details can be found > in the Design Doc: https://goo.gl/Ge321G. > > Performance impact on micro benchmarks depends on the element kind > and whether the user provides a comparison function. > For HoleySmi/HoleyElement we have a speedup between 1.5-1.8 across > the board. For Dictionary we are slower in all micro benchmarks (0.7). > For PackedSmi it depends on the call site and whether or not a > comparison function is used. > > Detailed numbers: https://goo.gl/mTyPSb > > Bug: v8:7382 > Change-Id: I50acabd2032af0bc01d36b0de0f555d66be56a7e > Reviewed-on: https://chromium-review.googlesource.com/1061523 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53481} Bug: v8:7382,v8:7806,chromium:849293 Change-Id: I176cb660d92eb174bd91685cb0a39f50c4cbaa69 Reviewed-on: https://chromium-review.googlesource.com/1086827 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53511}
2018-06-05 07:54:49 +00:00
[csa] Move NumberIsNaN to Torque This CL implements NumberIsNaN in Torque and removes it from the CodeStubAssembler. It is currently used in TypedArray.p.sort and Array.p.sort. R=jgruber@chromium.org Change-Id: Iaaa81901f89c0df68997d4501607b302a0449012 Reviewed-on: https://chromium-review.googlesource.com/1092532 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53611}
2018-06-08 11:12:59 +00:00
// Return true iff number is NaN.
macro NumberIsNaN(number: Number): bool {
if (TaggedIsSmi(number)) return false;
let value: float64 = convert<float64>(unsafe_cast<HeapNumber>(number));
return value != value;
}
[torque][cleanup] Move ToBoolean to base.tq This CL moves the ToBoolean function from data-view.tq to base.tq. It used to be in data-view.tq because we couldn't call macros from one file to the other but this has been fixed now, and it makes more sense to have it there. Change-Id: Id201979eacbeb4307ff7d515db48377490d5bed7 Reviewed-on: https://chromium-review.googlesource.com/1104683 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53837}
2018-06-18 16:06:22 +00:00
extern macro BranchIfToBooleanIsTrue(Object): never labels Taken, NotTaken;
macro ToBoolean(obj: Object): bool {
[torque]: Fix sharing of re-opened namespaces In the process, create a shared array utility GetLengthProperty that fast-paths accessing the length properties of JSArray. Bug: v8:7793 Change-Id: I6d7f0007c162794773dc0fc3e8bf12b3adf12fa0 Reviewed-on: https://chromium-review.googlesource.com/1116221 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54133}
2018-07-02 10:45:24 +00:00
if (BranchIfToBooleanIsTrue(obj)) {
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
return true;
[torque]: Fix sharing of re-opened namespaces In the process, create a shared array utility GetLengthProperty that fast-paths accessing the length properties of JSArray. Bug: v8:7793 Change-Id: I6d7f0007c162794773dc0fc3e8bf12b3adf12fa0 Reviewed-on: https://chromium-review.googlesource.com/1116221 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#54133}
2018-07-02 10:45:24 +00:00
} else {
[torque] Change syntax for "external constants" This CL changes the syntax for external constants to better reflect for what they are actually used. Drive-by change: Ran the format tool on base.tq. R=danno@chromium.org, tebbi@chromium.org Bug: v8:7793 Change-Id: Ie49c28b9c95a05846a2d9801f01b11e5a58d72d9 Reviewed-on: https://chromium-review.googlesource.com/1111706 Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53963}
2018-06-22 08:26:19 +00:00
return false;
[torque][cleanup] Move ToBoolean to base.tq This CL moves the ToBoolean function from data-view.tq to base.tq. It used to be in data-view.tq because we couldn't call macros from one file to the other but this has been fixed now, and it makes more sense to have it there. Change-Id: Id201979eacbeb4307ff7d515db48377490d5bed7 Reviewed-on: https://chromium-review.googlesource.com/1104683 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#53837}
2018-06-18 16:06:22 +00:00
}
}
Reference in New Issue Copy Permalink