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

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

375 lines
16 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';
type Object generates 'TNode<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
type int32 generates 'TNode<Int32T>' constexpr 'int32_t';
type intptr generates 'TNode<IntPtrT>' constexpr 'intptr_t';
type float64 generates 'TNode<Float64T>' constexpr 'double';
type bool generates 'TNode<BoolT>' constexpr 'bool';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type int31 extends int32 generates 'TNode<Int32T>' constexpr 'int32_t';
type RawPtr generates 'TNode<RawPtrT>' constexpr 'void*';
Torque: Implement 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 Number extends Object generates 'TNode<Number>';
type Smi extends Number generates 'TNode<Smi>';
type HeapObject extends Object generates 'TNode<HeapObject>';
[torque] implement function pointers to builtins This CL adds the new type expression builtin(Context, ArgType1, ...) => ReturnType and allows to use Torque-defined builtins as values of this type, as well as calling values of this type. The new function pointer types are subtypes of Code. Change-Id: Ib7ba3ce6ef7a8591a4c79230dd189fd25698d5b9 Reviewed-on: https://chromium-review.googlesource.com/1060056 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53217}
2018-05-16 14:00:35 +00:00
type AbstractCode extends HeapObject generates 'TNode<AbstractCode>';
type Code extends AbstractCode generates 'TNode<Code>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type JSReceiver extends HeapObject generates 'TNode<JSReceiver>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type Context extends HeapObject generates 'TNode<Context>';
type String extends HeapObject generates 'TNode<String>';
type Oddball extends HeapObject generates 'TNode<Oddball>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type HeapNumber extends HeapObject generates 'TNode<HeapNumber>';
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>';
[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>';
[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 Callable extends JSReceiver generates 'TNode<JSReceiver>';
[torque] Map Torque's JSFunction to V8's JSFunction. The 'generates' clause was missing (so I suppose it got mapped to JSReceiver). Change-Id: I146546921e552f17dbadf74082b31315bf868bf7 Reviewed-on: https://chromium-review.googlesource.com/1032434 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#53093}
2018-04-27 11:01:21 +00:00
type JSFunction extends Callable generates 'TNode<JSFunction>';
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
type Map extends HeapObject generates 'TNode<Map>';
type FixedArrayBase extends HeapObject generates 'TNode<FixedArrayBase>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
type FixedArray extends FixedArrayBase generates 'TNode<FixedArray>';
type FixedDoubleArray extends FixedArrayBase generates
'TNode<FixedDoubleArray>';
[typedarray] Change TypedArray.p.sort implementation. This CL uses the new function pointers and generic features of Torque to improve the performance of TypedArray.p.sort. Instead of one Load/Store builtin that dispatches at runtime based on the element kind, there are now many small builtins (one for each element kind). The sorting algorithm then uses function pointers to those small builtins, which get set once. Changes in the relevant benchmarks: Benchmark Original (JS) Current This CL IntTypes 83.9 202.3 240.7 BigIntTypes 32.1 47.2 53.3 FloatTypes 99.3 109.3 129.3 Bug: v8:7382 Change-Id: I8684410524d546615b19f6edcbfdc615068196aa Reviewed-on: https://chromium-review.googlesource.com/1070069 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53322}
2018-05-24 09:25:58 +00:00
type FixedTypedArrayBase extends FixedArrayBase generates
'TNode<FixedTypedArrayBase>';
type FixedTypedArray extends FixedTypedArrayBase generates
'TNode<FixedTypedArray>';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type JSArrayBuffer extends JSObject generates 'TNode<JSArrayBuffer>';
type JSArrayBufferView extends JSObject generates 'TNode<JSArrayBufferView>';
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
type JSTypedArray extends JSArrayBufferView generates 'TNode<JSTypedArray>';
[torque] Move remaining DataView getters to Torque This CL completely removes the C++ builtin implementation of the DataView.prototype.buffer, DataView.prototype.byteLength, and DataView.prototype.byteOffset getters, and moves them to a Torque implementation (that still relies on a bit of CSA). Change-Id: Id46678ae709c3787b7b93d0f78bd2a6e16e00f7b Reviewed-on: https://chromium-review.googlesource.com/1070369 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53339}
2018-05-24 13:43:57 +00:00
type JSDataView extends JSArrayBufferView generates 'TNode<JSDataView>';
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type InstanceType generates 'TNode<Int32T>' constexpr 'InstanceType';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
type ElementsKind generates 'TNode<Int32T>' constexpr 'ElementsKind';
type LanguageMode generates 'TNode<Smi>' constexpr 'LanguageMode';
type ExtractFixedArrayFlags generates
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'TNode<Smi>' constexpr 'ExtractFixedArrayFlags';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
type MessageTemplate constexpr 'MessageTemplate';
type HasPropertyLookupMode constexpr 'HasPropertyLookupMode';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[typedarray] Change TypedArray.p.sort implementation. This CL uses the new function pointers and generic features of Torque to improve the performance of TypedArray.p.sort. Instead of one Load/Store builtin that dispatches at runtime based on the element kind, there are now many small builtins (one for each element kind). The sorting algorithm then uses function pointers to those small builtins, which get set once. Changes in the relevant benchmarks: Benchmark Original (JS) Current This CL IntTypes 83.9 202.3 240.7 BigIntTypes 32.1 47.2 53.3 FloatTypes 99.3 109.3 129.3 Bug: v8:7382 Change-Id: I8684410524d546615b19f6edcbfdc615068196aa Reviewed-on: https://chromium-review.googlesource.com/1070069 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53322}
2018-05-24 09:25:58 +00:00
const NO_ELEMENTS: constexpr ElementsKind = 'NO_ELEMENTS';
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
const PACKED_SMI_ELEMENTS: constexpr ElementsKind = 'PACKED_SMI_ELEMENTS';
const HOLEY_SMI_ELEMENTS: constexpr ElementsKind = 'HOLEY_SMI_ELEMENTS';
const PACKED_ELEMENTS: constexpr ElementsKind = 'PACKED_ELEMENTS';
const HOLEY_ELEMENTS: constexpr ElementsKind = 'HOLEY_ELEMENTS';
const PACKED_DOUBLE_ELEMENTS: constexpr ElementsKind = 'PACKED_DOUBLE_ELEMENTS';
const HOLEY_DOUBLE_ELEMENTS: constexpr ElementsKind = 'HOLEY_DOUBLE_ELEMENTS';
const UINT8_ELEMENTS: constexpr ElementsKind = 'UINT8_ELEMENTS';
const INT8_ELEMENTS: constexpr ElementsKind = 'INT8_ELEMENTS';
const UINT16_ELEMENTS: constexpr ElementsKind = 'UINT16_ELEMENTS';
const INT16_ELEMENTS: constexpr ElementsKind = 'INT16_ELEMENTS';
const UINT32_ELEMENTS: constexpr ElementsKind = 'UINT32_ELEMENTS';
const INT32_ELEMENTS: constexpr ElementsKind = 'INT32_ELEMENTS';
const FLOAT32_ELEMENTS: constexpr ElementsKind = 'FLOAT32_ELEMENTS';
const FLOAT64_ELEMENTS: constexpr ElementsKind = 'FLOAT64_ELEMENTS';
const UINT8_CLAMPED_ELEMENTS: constexpr ElementsKind = 'UINT8_CLAMPED_ELEMENTS';
const BIGUINT64_ELEMENTS: constexpr ElementsKind = 'BIGUINT64_ELEMENTS';
const BIGINT64_ELEMENTS: constexpr ElementsKind = 'BIGINT64_ELEMENTS';
[typedarray] Change TypedArray.p.sort implementation. This CL uses the new function pointers and generic features of Torque to improve the performance of TypedArray.p.sort. Instead of one Load/Store builtin that dispatches at runtime based on the element kind, there are now many small builtins (one for each element kind). The sorting algorithm then uses function pointers to those small builtins, which get set once. Changes in the relevant benchmarks: Benchmark Original (JS) Current This CL IntTypes 83.9 202.3 240.7 BigIntTypes 32.1 47.2 53.3 FloatTypes 99.3 109.3 129.3 Bug: v8:7382 Change-Id: I8684410524d546615b19f6edcbfdc615068196aa Reviewed-on: https://chromium-review.googlesource.com/1070069 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53322}
2018-05-24 09:25:58 +00:00
type FixedUint8Array extends FixedTypedArray;
type FixedInt8Array extends FixedTypedArray;
type FixedUint16Array extends FixedTypedArray;
type FixedInt16Array extends FixedTypedArray;
type FixedUint32Array extends FixedTypedArray;
type FixedInt32Array extends FixedTypedArray;
type FixedFloat32Array extends FixedTypedArray;
type FixedFloat64Array extends FixedTypedArray;
type FixedUint8ClampedArray extends FixedTypedArray;
type FixedBigUint64Array extends FixedTypedArray;
type FixedBigInt64Array extends FixedTypedArray;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
const kAllFixedArrays: constexpr ExtractFixedArrayFlags =
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
'ExtractFixedArrayFlag::kAllFixedArrays';
const kCOWMap: Map = 'LoadRoot(Heap::kFixedCOWArrayMapRootIndex)';
const kEmptyFixedArray: FixedArrayBase =
'UncheckedCast<FixedArrayBase>(LoadRoot(Heap::kEmptyFixedArrayRootIndex))';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kInvalidArrayLength: constexpr MessageTemplate =
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
'MessageTemplate::kInvalidArrayLength';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kCalledNonCallable: constexpr MessageTemplate =
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
'MessageTemplate::kCalledNonCallable';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kCalledOnNullOrUndefined: constexpr MessageTemplate =
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
'MessageTemplate::kCalledOnNullOrUndefined';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kHasProperty: constexpr HasPropertyLookupMode = 'kHasProperty';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
const kMaxSafeInteger: constexpr float64 = 'kMaxSafeInteger';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kNotTypedArray: constexpr MessageTemplate =
'MessageTemplate::kNotTypedArray';
const kDetachedOperation: constexpr MessageTemplate =
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
'MessageTemplate::kDetachedOperation';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kBadSortComparisonFunction: constexpr MessageTemplate =
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
'MessageTemplate::kBadSortComparisonFunction';
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
const kIncompatibleMethodReceiver: constexpr MessageTemplate =
[torque] Move remaining DataView getters to Torque This CL completely removes the C++ builtin implementation of the DataView.prototype.buffer, DataView.prototype.byteLength, and DataView.prototype.byteOffset getters, and moves them to a Torque implementation (that still relies on a bit of CSA). Change-Id: Id46678ae709c3787b7b93d0f78bd2a6e16e00f7b Reviewed-on: https://chromium-review.googlesource.com/1070369 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53339}
2018-05-24 13:43:57 +00:00
'MessageTemplate::kIncompatibleMethodReceiver';
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
const Hole: Oddball = 'TheHoleConstant()';
const Null: Oddball = 'NullConstant()';
const Undefined: Oddball = 'UndefinedConstant()';
const True: Boolean = 'TrueConstant()';
const False: Boolean = 'FalseConstant()';
const true: constexpr bool = 'true';
const false: constexpr bool = 'false';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[cleanup] Renamed LanguageMode constants in torque R=tebbi@chromium.org Change-Id: Id524c8239f99fc26ac5cd19cbdea39dba62f2c3f Reviewed-on: https://chromium-review.googlesource.com/1071650 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Simon Zünd <szuend@google.com> Cr-Commit-Position: refs/heads/master@{#53331}
2018-05-24 11:19:32 +00:00
const kStrict: constexpr LanguageMode = 'LanguageMode::kStrict';
const kSloppy: constexpr LanguageMode = 'LanguageMode::kSloppy';
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro Print(Object);
extern macro DebugBreak();
extern macro ToInteger_Inline(Context, Object): Number;
extern macro ToLength_Inline(Context, Object): Number;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
extern macro ToNumber_Inline(Context, Object): Number;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro ToString_Inline(Context, Object): String;
extern macro GetProperty(Context, Object, Object): Object;
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
extern macro HasProperty(
HeapObject, Object, Context, constexpr HasPropertyLookupMode): Oddball;
extern macro ThrowRangeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate): never;
extern macro ThrowTypeError(Context, constexpr MessageTemplate, Object): never;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern macro ArraySpeciesCreate(Context, Object, Number): Object;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro EnsureArrayPushable(Map): ElementsKind labels Bailout;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern builtin ToObject(Context, Object): Object;
[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;
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);
extern runtime StringEqual(Context, String, String): Oddball;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro Word32Equal(int32, int32): bool;
extern operator '!=' macro Word32NotEqual(int32, int32): bool;
extern operator '<' macro Int32LessThan(int32, int32): bool;
extern operator '>' macro Int32GreaterThan(int32, int32): bool;
extern operator '<=' macro Int32LessThanOrEqual(int32, int32): bool;
extern operator '>=' macro Int32GreaterThanOrEqual(int32, int32): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro SmiEqual(Smi, Smi): bool;
extern operator '!=' macro SmiNotEqual(Smi, Smi): bool;
extern operator '<' macro SmiLessThan(Smi, Smi): bool;
extern operator '<=' macro SmiLessThanOrEqual(Smi, Smi): bool;
extern operator '>' macro SmiGreaterThan(Smi, Smi): bool;
extern operator '>=' macro SmiGreaterThanOrEqual(Smi, Smi): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add the ability to test Torque functionality with cctest In the process, add a few simple tests for "constexpr" expressions, which identified a few bugs that are also fixed in this CL. Change-Id: I97486c781572642d2b574b92133b1f9cda3db592 Reviewed-on: https://chromium-review.googlesource.com/1055493 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53135}
2018-05-13 10:10:44 +00:00
extern operator '==' macro ElementsKindEqual(
constexpr ElementsKind, constexpr ElementsKind): constexpr bool;
extern macro IsFastElementsKind(constexpr ElementsKind): constexpr bool;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro SmiAbove(Smi, Smi): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro WordEqual(intptr, intptr): bool;
extern operator '!=' macro WordNotEqual(intptr, intptr): bool;
extern operator '<' macro IntPtrLessThan(intptr, intptr): bool;
extern operator '>' macro IntPtrGreaterThan(intptr, intptr): bool;
extern operator '<=' macro IntPtrLessThanOrEqual(intptr, intptr): bool;
extern operator '>=' macro IntPtrGreaterThanOrEqual(intptr, intptr): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro Float64Equal(float64, float64): bool;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'<' macro BranchIfNumberLessThan(Number, Number): never labels Taken, NotTaken;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'<=' macro BranchIfNumberLessThanOrEqual(Number, Number): never labels Taken,
NotTaken;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
'>' macro BranchIfNumberGreaterThan(Number, Number): never labels Taken,
NotTaken;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '>=' macro BranchIfNumberGreaterThanOrEqual(Number, Number):
[torque] 'bool' is now 'true|false' not 'yes|no' In the process, rename Boolean constants (i.e. JavaScript constants), to 'True' and 'False'. This uncovered a bug in the internal handling of True/False labels was fixed (they shouldn't be Values and Torque shouldn't conflate Labels with other Declarables, throwing exceptions when they're improperly used in the wrong context). Furthermore, the internal labels used for True and False for if statements have been renamed so that they can't be aliased from user Torque code. Change-Id: I09dbd2241d2bc2f1daff53862dee1b601810060c Reviewed-on: https://chromium-review.googlesource.com/1044370 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53026}
2018-05-04 15:55:55 +00:00
never labels Taken,
NotTaken;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '==' macro WordEqual(Object, Object): bool;
extern operator '!=' macro WordNotEqual(Object, Object): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '+' macro SmiAdd(Smi, Smi): Smi;
extern operator '-' macro SmiSub(Smi, Smi): Smi;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern operator '>>>' macro SmiShr(Smi, constexpr int31): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator '+' macro IntPtrAdd(intptr, intptr): intptr;
extern operator '-' macro IntPtrSub(intptr, intptr): intptr;
[typedarray] Implement TypedArray.p.sort using Torque. This CL implements TypedArray.p.sort in Torque. The Torque version works basically the same as the existing JS builtin: When no comparison function is provided, the C++ fast path builtin is used. Otherwise a quicksort written in Torque is used, with a InsertionSort fallback for smaller arrays. The JS quicksort implementation also containes a more elaborate third pivot calculation for larger arrays. This is currently not done. Reported benchmark results are only for those, where a custom comparison function is provided. The numbers for the C++ path stayed the same. Benchmark Current (JS) Torque Speedup IntTypes 83.9 263.7 3.1 BigIntTypes 32.1 54.6 1.7 FloatTypes 99.3 138.7 1.4 R=danno@chromium.org, jgruber@chromium.org Bug: v8:7382 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7abe7ceff525bab24f302d2f06b5961cca770d24 Reviewed-on: https://chromium-review.googlesource.com/1021691 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52776}
2018-04-25 08:14:09 +00:00
extern operator '>>>' macro WordShr(intptr, intptr): intptr;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
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
'.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
'[]' macro GetArgumentValue(constexpr Arguments, intptr): Object;
extern operator
'[]' macro GetArgumentValueSmiIndex(constexpr Arguments, Smi): 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;
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] 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
extern operator 'cast<>' macro TaggedToJSDataView(
Object): JSDataView labels 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
extern operator
'cast<>' macro TaggedToHeapObject(Object): HeapObject labels CastError;
extern operator 'cast<>' macro TaggedToSmi(Object): Smi labels CastError;
extern operator
'cast<>' macro TaggedToJSArray(Object): JSArray labels CastError;
extern operator
'cast<>' macro TaggedToCallable(Object): Callable labels CastError;
extern operator 'cast<>' macro ConvertFixedArrayBaseToFixedArray(
FixedArrayBase): FixedArray labels CastError;
extern operator 'cast<>' macro ConvertFixedArrayBaseToFixedDoubleArray(
FixedArrayBase): FixedDoubleArray labels CastError;
[torque] require exact match in return type for cast-like operations This fixes the bug that cast<A>(...) could be interpreted as cast<B>(...) if B is a subtype of A. Bug: v8:7793 Change-Id: Ia03ce832f8c14ced09114d41c935be06d4629d99 Reviewed-on: https://chromium-review.googlesource.com/1075890 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#53397}
2018-05-29 08:05:57 +00:00
extern operator 'cast<>' macro TaggedToNumber(
Object): Number labels CastError;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro AllocateHeapNumberWithValue(float64): HeapNumber;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern implicit operator
[cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere Bug: v8:7754 Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b Reviewed-on: https://chromium-review.googlesource.com/1071654 Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53398}
2018-05-29 08:34:01 +00:00
'convert<>' macro NumberConstant(constexpr float64): Number;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern implicit operator
'convert<>' macro IntPtrConstant(constexpr int31): intptr;
extern implicit operator
'convert<>' macro Int32Constant(constexpr int31): int32;
extern implicit operator 'convert<>' macro SmiConstant(constexpr int31): Smi;
extern implicit operator
'convert<>' macro NumberConstant(constexpr int31): Number;
extern implicit operator 'convert<>' macro BoolConstant(constexpr bool): bool;
extern implicit operator 'convert<>' macro LanguageModeConstant(
constexpr LanguageMode): LanguageMode;
[typedarray] Change TypedArray.p.sort implementation. This CL uses the new function pointers and generic features of Torque to improve the performance of TypedArray.p.sort. Instead of one Load/Store builtin that dispatches at runtime based on the element kind, there are now many small builtins (one for each element kind). The sorting algorithm then uses function pointers to those small builtins, which get set once. Changes in the relevant benchmarks: Benchmark Original (JS) Current This CL IntTypes 83.9 202.3 240.7 BigIntTypes 32.1 47.2 53.3 FloatTypes 99.3 109.3 129.3 Bug: v8:7382 Change-Id: I8684410524d546615b19f6edcbfdc615068196aa Reviewed-on: https://chromium-review.googlesource.com/1070069 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53322}
2018-05-24 09:25:58 +00:00
extern operator
'convert<>' macro Int32Constant(constexpr ElementsKind): ElementsKind;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern implicit operator 'convert<>' macro SmiFromInt32(ElementsKind): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator 'convert<>' macro ChangeInt32ToTagged(int32): Number;
extern operator 'convert<>' macro TruncateWordToWord32(intptr): int32;
extern operator 'convert<>' macro SmiTag(intptr): Smi;
[typedarray] Change Torque sort implementation This CL changes how TypedArray.p.sort is implemented in Torque, mainly to address the binary memory size of the builtin. With this CL the memory comes down from 53611 to 4215 (as reported by --print-builtin-size on a x64.release build). With the following performance impact on the relevant benchmarks: Benchmark Original (JS) Torque (initial) This CL IntTypes 83.9 263.7 202.3 BigIntTypes 32.1 54.6 47.2 FloatTypes 99.3 138.7 109.3 This is achieved by pushing the Load/Store dispatch based on the elements kind into separate builtins that are executed for each load/store. This results in only one version of the sorting algorithm instead of one version per elements kind. R=jgruber@chromium.org Bug: chromium:837282 Change-Id: I7fe2da3cbfd01531d070128126a0d56d3dd6bdcc Reviewed-on: https://chromium-review.googlesource.com/1033744 Commit-Queue: Simon Zünd <szuend@google.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52937}
2018-05-03 07:35:25 +00:00
extern operator 'convert<>' macro SmiFromInt32(int32): Smi;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
extern operator 'convert<>' macro SmiUntag(Smi): intptr;
[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;
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;
extern operator
'[]=' macro StoreFixedArrayElement(FixedArray, intptr, Object): void;
extern operator
'[]=' macro StoreFixedArrayElementSmi(FixedArray, Smi, Object): void;
[torque]: Add constexpr keyword/types for compile-time evaluation Torque expressions of type constexpr are evaluated at compile-time rather than runtime. They are backed by C++ types rather than TNode<X> types, so the macro functions that are called by generated C++ code expect values to be computed when the snapshot is generated rather than by TurboFan-generated code. Specifically, "if" statements can have a constexpr modifier. With this modifier, a type of "constexpr bool" is expected rather than "bool", and in that case instead of generating a CSA BranchIf, it generates a C++ "if (<bool expression>)" that generates code for only the true or false path based on the bool value at torque-execution (compile time) rather than generating both paths (including inserting phi nodes for variables modified on either branch at the re-merge at the end of the if) and dynamically dispatching to the true or false path during d8/Chrome/node.js execution (runtime) using a CSA BranchIf. Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d Reviewed-on: https://chromium-review.googlesource.com/1042085 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53001}
2018-05-04 15:04:42 +00:00
extern macro IsFastElementsKind(ElementsKind): bool;
extern macro IsFastSmiOrTaggedElementsKind(ElementsKind): bool;
extern macro IsFastSmiElementsKind(ElementsKind): bool;
[Builtins] Torque version of Array.prototype.forEach() BUG=v8:7672 Change-Id: I0c157ce88b31312dfbea7a149c1d9fbdfb398278 Reviewed-on: https://chromium-review.googlesource.com/1013524 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#53091}
2018-05-09 08:16:07 +00:00
extern macro IsHoleyFastElementsKind(ElementsKind): bool;
Torque: Implement a DSL for CSA An overview of motivation behind Torque and some of its principles can be found here: https://bit.ly/2qAI5Ep Note that there is quite a bit of work left to do in order to get Torque production-ready for any non-trivial amount of code, but landing the prototype as-is will allow for much faster iteration. Bugs will be filed for all of the big-ticket items that are not landing blockers but called out in this patch as important to fix. Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73 Reviewed-on: https://chromium-review.googlesource.com/845682 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#52618}
2018-04-16 09:24:22 +00:00
[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 AllocateFixedArray(constexpr ElementsKind, Smi): FixedArray;
extern macro AllocateFixedArray(constexpr ElementsKind, Smi, Map): 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(
[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
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 {
return HasProperty(cast<HeapObject>(o) otherwise CastError, p, c, f);
}
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;
extern macro TaggedIsCallable(Object): bool;
extern macro IsDetachedBuffer(JSArrayBuffer): bool;
Reference in New Issue Copy Permalink