Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.
Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
Changes:
- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
* Resume generator reads the state out and marks the generator as
'executing'.
* RestoreGeneratorRegisters reloads the registers from
the generator.
+ this required adding support for output register list.
- Introduced generator_object_ register in the bytecode generator.
* in subsequent CLs, I will make better use of it, the goal is
to get rid if the .generator_object local variable.
- Taught register optimizer to flush unassigned registers.
BUG=v8:6379
Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
Rather than trying to pre-calculate the number of contexts required during
scope analysis, instead just allocate context registers in the register
allocator. This reduces frame size a bit due to reusing of registers when
the context isn't pushed.
BUG=v8:6322, chromium:716265
Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89
Reviewed-on: https://chromium-review.googlesource.com/514087
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45522}
Special cases addition expressions where one of the sides is known to be a
string to enable chains of string additions to be transformed into a series
of ToPrimitiveToString operations followed by a single string concatenation
at the end of the chain of additions. This should avoid creating temporary
strings for each of the string additions (in essence this is an automated
string builder).
BUG=v8:6243
Change-Id: I44977d6dad00ee906f251c4bd9cab27e160c09d1
Reviewed-on: https://chromium-review.googlesource.com/493966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45453}
Introduce a new SwitchSmiTable bytecode for generators, which does a
table lookup for the accumulator value in a jump table stored in the
constant array pool. This removes the if-else chains at resumable
function/loop headers.
As a drive-by, add a scoped environment saving struct to the bytecode
graph builder.
Bug: v8:6351
Bug: v8:6366
Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0
Reviewed-on: https://chromium-review.googlesource.com/500271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45314}
BytecodeRegisterOptimizer had special handling for the case when parameters
is 0. This is not possible from valid javascript. It exists because some
tests do not take this into account. Fixed tests and removed the special
handling.
Also removed a TODO, which is already done here:
https://codereview.chromium.org/2227203002/
Bug: v8:4280,v8:6325
Change-Id: Idc17af12ad9292c13a6677aa4c8b88d21f4adf81
Reviewed-on: https://chromium-review.googlesource.com/490308
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45036}
Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.
As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.
Reland of https://chromium-review.googlesource.com/c/463287 after fixing
tests in https://codereview.chromium.org/2813873002.
Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5
Reviewed-on: https://chromium-review.googlesource.com/474752
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44582}
All the optimizations have now been moved to either the BytecodeGenerator
or the BytecodeArrayWriter/Builder.
BUG=v8:6194
Change-Id: Ie5c5d55e824c94ffb503af376c72bc64ad1f6f81
Reviewed-on: https://chromium-review.googlesource.com/469349
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44564}
This reverts commit 751e893591.
Reason for revert: Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/14885
See:
https://github.com/v8/v8/wiki/Blink-layout-tests
Original change's description:
> [ignition] Add call bytecodes for undefined receiver
>
> Adds a collection of call bytecodes which have an implicit undefined
> receiver argument, for cases such as global calls where we know that the
> receiver has to be undefined. This way we can skip an LdaUndefined,
> decrease bytecode register pressure, and set a more accurate
> ConvertReceiverMode on the interpreter and TurboFan call.
>
> As a side effect, the "normal" Call bytecode now becomes a rare case
> (only with calls and super property calls), so we get rid of its 0-2
> argument special cases and modify CallProperty[N] to use the
> NotNullOrUndefined ConvertReceiverMode.
>
> Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
> Reviewed-on: https://chromium-review.googlesource.com/463287
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44530}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com,v8-x87-ports@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I7629dec609d0ec938ce7105d6c1c74884e5f9272
Reviewed-on: https://chromium-review.googlesource.com/474744
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44548}
Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.
As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.
Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
Reviewed-on: https://chromium-review.googlesource.com/463287
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44530}
This relands commit d3e9aade0f. The original CL was reverted speculatively but didn't cause the buildbot failure.
Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
>
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
>
> In the process, adds Smi bytecode variants for all binary operations, adding
> - MulSmi
> - DivSmi
> - ModSmi
> - BitwiseXorSmi
> - ShiftRightLogical
>
> BUG=v8:6194
>
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}
TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6194
Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8
Reviewed-on: https://chromium-review.googlesource.com/472746
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44511}
This reverts commit d3e9aade0f.
Reason for revert: Speculative for:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/4449
Bisect points to this CL.
Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
>
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
>
> In the process, adds Smi bytecode variants for all binary operations, adding
> - MulSmi
> - DivSmi
> - ModSmi
> - BitwiseXorSmi
> - ShiftRightLogical
>
> BUG=v8:6194
>
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,ishell@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6194
Change-Id: If57dbdbe40be77804bf437463b855d3167e2d473
Reviewed-on: https://chromium-review.googlesource.com/471308
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44488}
Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
literals in the BytecodeGenerator. This enables us to perform the
transformation for literals on either side for commutative operations, and
Avoids having to do the check on every bytecode in the peephole optimizer.
In the process, adds Smi bytecode variants for all binary operations, adding
- MulSmi
- DivSmi
- ModSmi
- BitwiseXorSmi
- ShiftRightLogical
BUG=v8:6194
Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
Reviewed-on: https://chromium-review.googlesource.com/466246
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44477}
Make Ignition collect BinaryOperationFeedback on ToNumber, using the
shared type feedback slot with the following Inc/Dec bytecode, and use
this feedback in TurboFan to turn the ToNumber(x) operation into a
SpeculativeNumberMultiply(x,1) with the feedback hint.
R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:6214,v8:5267
Review-Url: https://codereview.chromium.org/2804813003
Cr-Commit-Position: refs/heads/master@{#44440}
Move the ToBoolean elision in the BytecodeGenerator instead of the
peephole optimizer. Adds a TypeHint mechanism to the ExpressionResult
to enable passing of type hints through the ast visitor.
BUG=v8:6194
Change-Id: Ic55506ba11b213f7459250004d3f18cab04ee9b3
Reviewed-on: https://chromium-review.googlesource.com/467208
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44415}
Translates code of the form 'if (x === undefined)' into the JumpIfUndefined
bytecode, and similarly for comparisons with null. Also adds bytecodes for
JumpIfNotUndefined / Null.
Moves the peephole optimization for CompareUndefined out of the peephole
optimizer and into the BytecodeGenerator, having the side-effect of enabling
it for comparisons with undefined on both side of the compare operation.
BUG=v8:6107
Review-Url: https://codereview.chromium.org/2793923002
Cr-Commit-Position: refs/heads/master@{#44341}
The parameter indices are shifted by 1 in BytecodeArrayBuilder
because the receiver is variable at index 0 and not -1.
Split BytecodeArrayBuilder::Parameter(index) method into
Receiver() (same as Parameter(-1)) and
Parameter(index).
This way we avoid confusing (index+1) counting in BytecodeGenerator().
BUG=
Change-Id: Id87ec7c708cecfc3108011994f3177f483772bcc
Reviewed-on: https://chromium-review.googlesource.com/461904
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44262}
- Introduce new struct AsyncGeneratorRequest, which holds
information pertinent to resuming execution of an
AsyncGenerator, such as the Promise associated with the async
generator request. It is intended to be used as a singly
linked list, and holds a pointer to the next item in te queue.
- Introduce JSAsyncGeneratorObject (subclass of
JSGeneratorObject), which includes several new internal fields
(`queue` which contains a singly linked list of
AsyncGeneratorRequest objects, and `await_input` which
contains the sent value from an Await expression (This is
necessary to prevent function.sent (used by yield*) from
having the sent value observably overwritten during
execution).
- Modify SuspendGenerator to accept a set of Flags, which
indicate whether the suspend is for a Yield or Await, and
whether it takes place on an async generator or ES6
generator.
- Introduce interpreter intrinsics and TF intrinsic lowering for
accessing the await input of an async generator
- Modify the JSGeneratorStore operator to understand whether or
not it's suspending for a normal yield, or an AsyncGenerator
Await. This ensures appropriate registers are stored.
- Add versions of ResumeGeneratorTrampoline which store the
input value in a different field depending on wether it's an
AsyncGenerator Await resume, or an ordinary resume. Also modifies
whether debug code will assert that the generator object is a
JSGeneratorObject or a JSAsyncGeneratorObject depending on the
resume type.
BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.orgTBR=marja@chromium.org
Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
Some of the StrictEquality comparisons do not require feedback (for ex: in
try-finally, generators). This cl introduces StrictEqualityNoFeedback bytecode
to be used in such cases. With this change, we no longer have to check if the
type feedback slot is valid in compare bytecode handlers.
This is the first step in reworking the compare bytecode handler to avoid
duplicate checks when collecting feedback and when performing the operation.
BUG=v8:4280
Change-Id: Ia650fd43c0466b8625d3ce98c39ed1073ba42a6b
Reviewed-on: https://chromium-review.googlesource.com/455778
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44020}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
For now, has a test that compares the stdout of --type-profile in test/message. We
will remove this test when --type-profile is fully integrated in
the debugger protocol. Adding
the test in test/inspector does not work, because the inspector
test itself consists of JavaScript code that would convolute the
output and be non-deterministic under stress.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43866}
Reason for revert:
Still flaky
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43849}
> Committed: 18c35e4958TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2745413006
Cr-Commit-Position: refs/heads/master@{#43852}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43846}
Committed: 5c32287390
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43849}
Reason for revert:
Flaky under stress. Fix first.
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2747383004
Cr-Commit-Position: refs/heads/master@{#43847}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43846}
Adds a TestTypeof bytecode to deal with comparisons of the form:
typeof(object) === 'string';
Also adds support to Turbofan to perform these comparisons without
inserting checkpoints.
BUG=v8:4280,v8:5267
Change-Id: Ib5cc1c6816dfe70a4120838d8eada2fc0267750f
Reviewed-on: https://chromium-review.googlesource.com/454837
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43832}
Reason for revert:
gcc bot is now flaky https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11863
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2754573002
Cr-Commit-Position: refs/heads/master@{#43805}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43804}
Reason for revert:
gcc bot has problems with this: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/11858
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org,franzih@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2749673003
Cr-Commit-Position: refs/heads/master@{#43798}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43791}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Original-Commit-Position: refs/heads/master@{#43290}
Committed: 00d6f1f80a
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43700}
The parser already changes all negative equality comparison operations
to their positive pendants in {ParserBase::ParseBinaryExpression}. No
other source of the Token::NE exists in the system. We can remove all
handling from the compiler and interpreter backends.
R=bmeurer@chromium.org
Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10
Reviewed-on: https://chromium-review.googlesource.com/449716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43627}
Reason for revert:
Due to arm64 failures
Original issue's description:
> [interpreter] Create custom call opcodes for specific argument counts
>
> Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
> and CallProperty2. Also share the bytecode handler code between between
> equivalent CallX and CallPropertyX handlers.
>
> Review-Url: https://codereview.chromium.org/2684993002
> Cr-Commit-Position: refs/heads/master@{#43290}
> Committed: 00d6f1f80aTBR=rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2709533002
Cr-Commit-Position: refs/heads/master@{#43308}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43290}
... which is used for initializing properties with non compile time values.
Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.
BUG=v8:5495, v8:4414
Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}
Removes handles from bytecode generation, instead storing
un-internalized AstValues (and other, similar values such as Scopes and
AstRawStrings) in the constant array builder.
This will allow us in the future to generate the bytecode before
internalizing the AST.
BUG=v8:5832
Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da
Reviewed-on: https://chromium-review.googlesource.com/439326
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43115}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Review-Url: https://codereview.chromium.org/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
Rename to Construct and ConstructWithSpread, to match the names of
the JSOperators used.
Unfortunately, I can't find a way for auto-formatting to stay happy unless we
change the indentation for the whole BYTECODE_LIST macro.
Review-Url: https://codereview.chromium.org/2663963003
Cr-Commit-Position: refs/heads/master@{#42840}
Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).
Review-Url: https://codereview.chromium.org/2641443002
Cr-Commit-Position: refs/heads/master@{#42638}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
Reason for revert:
Causes a few bugs caught by clusterfuzz.
Original issue's description:
> [Ignition/turbo] Add a CallWithSpread bytecode.
>
> Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
>
> BUG=v8:5511
>
> Review-Url: https://codereview.chromium.org/2629363002
> Cr-Commit-Position: refs/heads/master@{#42455}
> Committed: 4bae43471dTBR=bmeurer@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2642843002
Cr-Commit-Position: refs/heads/master@{#42470}
Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42455}
Moves constant element/property array building to be deferred for
igition and on-demand for the other compilers, and splits off the
object/array literal depth/flag initialisation from the array building.
BUG=v8:5832
Review-Url: https://codereview.chromium.org/2625873009
Cr-Commit-Position: refs/heads/master@{#42362}
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
Downside: this adds all kinds of weird includes in the .cc files.
(See design doc linked in the bug.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2622503002
Cr-Commit-Position: refs/heads/master@{#42140}
Add a feedback vector slot for computed property names in object
and class literals. Introduce new slot kind for storing
computed property names.
Change StaDataPropertyInLiteral to use the accumulator (again), so
we don't exceed Bytecodes::kMaxOperands.
We assume that most computed property names are
symbols. Therefore we should see performance
improvements, even if we deal with monomorphic ICs only.
This CL only collects feedback but does not use
it in Reduce() yet.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2587393006
Cr-Commit-Position: refs/heads/master@{#42082}
