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}
This removes the need for certain context scopes to skip popping the
context register. For the {incoming_context} the flag was already
obsolete, because its destructor would only run once the basic block
ended with a return. For {local_function_context} the same holds now
by moving handling of implicit returns into the body visitor.
R=rmcilroy@chromium.org
Change-Id: Icceaab1b30d7223b2b2f87a092a6580be7d7d675
Reviewed-on: https://chromium-review.googlesource.com/513963
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45511}
This avoids emitting redundant {PopContext} bytecode instructions when
non-local control-flow leaves the method body. It also folds multiple
such {PopContext} instructions into one, in case several scoping levels
are crossed at one. Only the expected context of the target of a local
control-flow transfer matters.
R=rmcilroy@chromium.org
TEST=debugger/regress/regress-crbug-724858
BUG=chromium:724858
Change-Id: Id4a47ae9fea25e75ae1af13619720b16a3975edf
Reviewed-on: https://chromium-review.googlesource.com/512545
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45507}
This patch also adds sharing of code target entries, which requires
sharing the RelocInfo for those entries as well. The disassembler
is also modified in order to print comments for the RelocInfo that
is now shared.
This improves the snapshot size for arm by about 4%.
BUG=
Review-Url: https://codereview.chromium.org/2869683004
Cr-Commit-Position: refs/heads/master@{#45497}
This reverts commit bdf70aa0e2.
Reason for revert: Breaks perf testing. Comma missing in json.
Original change's description:
> [Interpreter] Improve handling of a === true / false.
>
> Add support for direct jumping on True/False for strict equals of boolean
> literals. This improves the score for such comparisons by around 75% on
> baseline code, and by around 40x on optimized code for the added performance
> test.
>
> Bug=v8:6403
>
> Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb
> Reviewed-on: https://chromium-review.googlesource.com/509570
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45450}
TBR=rmcilroy@chromium.org,mythria@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug=v8:6403
Change-Id: I12b1868ba22354d056f38fe36e3c1e5fae5aa1b5
Reviewed-on: https://chromium-review.googlesource.com/509577
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45459}
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}
Add support for direct jumping on True/False for strict equals of boolean
literals. This improves the score for such comparisons by around 75% on
baseline code, and by around 40x on optimized code for the added performance
test.
Bug=v8:6403
Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb
Reviewed-on: https://chromium-review.googlesource.com/509570
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45450}
GeneratorClose is pretty simple, we can handle it in the interpreter.
BUG=v8:6351
Review-Url: https://codereview.chromium.org/2891353002
Cr-Commit-Position: refs/heads/master@{#45434}
This CL enforces passing an AssemblerDebugInfo object to Bind, most convently
acheived by the BIND macro.
Change-Id: I092714f10803f529d01d2fe716b96275b2bee806
Reviewed-on: https://chromium-review.googlesource.com/508729
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45433}
Split BytecodeGenerator::VisitSuspend into two pieces, one for
building the suspension code and one for resumption (these
are split into separate Build methods for convenience).
Each gets its own RegisterAllocationScope, which allows us to
reduce the register file size of the empty generator by 1.
For consistency, rename VisitGeneratorPrologue() to
BuildGeneratorPrologue() to match the names of the two
newly-created methods.
This relands the patch originally committed in
98927ea51b, as the test failure
due to that change was a code flushing bug. Code flushing was
disabled in de4a4095cf.
R=rmcilroy@chromium.org
Bug: v8:6379
Change-Id: Ifb4deafea99693c0a4e8646cf4e9884c7374cfc6
Reviewed-on: https://chromium-review.googlesource.com/508814
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45406}
Uses CheckSmi to force the switch argument to be a Smi, so that it can
be used as an input into a Switch node.
Change-Id: Ibec6beaeebc2168a3f80b86512c70a99d52f2575
Reviewed-on: https://chromium-review.googlesource.com/505621
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45397}
For a single deferred commands, using a jump table is overkill, so
instead simply test the token against the single entry.
Bug: v8:4280
Bug: v8:6218
Change-Id: I0300f640080705fb10f46ad4ed5791703fa4dd77
Reviewed-on: https://chromium-review.googlesource.com/506153
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45393}
Generate the code (extra runtime calls) for --trace-ignition support at
compile time, based on a #define (similar to TRACE_MAPS). Then check for
--trace-ignition at run-time when deciding whether to actually print
anything. This should make --trace-ignition less painful to use.
Note that --trace-igition is disabled by default, even on debug builds.
It has to be enabled with the gn arg "v8_enable_trace_ignition=true"
As a drive-by, TRACE_MAPS is renamed to V8_TRACE_MAPS, for consistency,
and SFI unique index (needed both by --trace-ignition and --trace-maps)
is cleaned up to be behind another #define.
Change-Id: I8dd0c62d0e6b7ee9c75541d45eb729dc03acbee9
Reviewed-on: https://chromium-review.googlesource.com/506203
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45346}
Since deferred return/async return/rethrow commands don't have an associated
statement, we can reuse their entries in the deferred command list.
Bug: v8:4280
Bug: v8:6218
Change-Id: Ic51fb735d4ea13ebea1d5e456ec5689c0d98a4ac
Reviewed-on: https://chromium-review.googlesource.com/506077
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45344}
This reverts commit 98927ea51b.
Reason for revert: Breaks Mac GC Stress bot.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/13299/steps/Mjsunit/logs/for-await-of
Original change's description:
> [ignition] Be smarter about register allocation in VisitSuspend
>
> Split BytecodeGenerator::VisitSuspend into two pieces, one for
> building the suspension code and one for resumption (these
> are split into separate Build methods for convenience).
> Each gets its own RegisterAllocationScope, which allows us to
> reduce the register file size of the empty generator by 1.
>
> For consistency, rename VisitGeneratorPrologue() to
> BuildGeneratorPrologue() to match the names of the two
> newly-created methods.
>
> Bug: v8:6379
> Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032
> Reviewed-on: https://chromium-review.googlesource.com/503593
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45318}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug: v8:6379
Change-Id: I787fc3811c4f33a8021cf9170d43a74ed9b55d1c
Reviewed-on: https://chromium-review.googlesource.com/506548
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45319}
Split BytecodeGenerator::VisitSuspend into two pieces, one for
building the suspension code and one for resumption (these
are split into separate Build methods for convenience).
Each gets its own RegisterAllocationScope, which allows us to
reduce the register file size of the empty generator by 1.
For consistency, rename VisitGeneratorPrologue() to
BuildGeneratorPrologue() to match the names of the two
newly-created methods.
Bug: v8:6379
Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032
Reviewed-on: https://chromium-review.googlesource.com/503593
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45318}
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}
This is the last in the series of simplifying the logic to collect feedback
in compare bytecode handlers. This cl inlines the type feedback collection
for the relational compare (lessthan, lessthan or equal, greater than,
gerater than or equal) bytecode handlers.
Bug: v8:4280
Change-Id: I4a896c9cbe5628c76785882c0632bfa07b18b099
Reviewed-on: https://chromium-review.googlesource.com/500309
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45296}
This lets us avoid allocating the "this" variable for every
generator, since the BytecodeGenerator can directly read
the receiver via BytecodeArrayBuilder::Receive() when passing
it into %_CreateJSGeneratorObject.
Bug: v8:6351
Change-Id: Ib5e1f3303b6b5d5fc051ce76ea62129fd6afac65
Reviewed-on: https://chromium-review.googlesource.com/500507
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#45281}
Bug: v8:6351
Change-Id: I6a5b44486bac87e2b3cb9aa93808b2c7964d6202
Reviewed-on: https://chromium-review.googlesource.com/499508
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45205}
Before this, --print-bytecode flag was available in all Release builds
but did not actually print the bytecodes because OBJECT_PRINT is not set.
The output was pretty confusing:
[generating bytecode for function: ]
000002115442ABE9 <BytecodeArray[27]>[generating bytecode for function: main]
000002115442B069 <BytecodeArray[114]>[generating bytecode for function: Primes]
000002115442B729 <BytecodeArray[63]>[generating bytecode for function: Int32Array]
000002115442BB51 <BytecodeArray[175]>[generating bytecode for function: Primes.getPrimeCount]
000002115442BE81 <BytecodeArray[7]>[generating bytecode for function: Primes.isPrimeDivisible]
000002115442BFC9 <BytecodeArray[71]>[generating bytecode for function: Primes.addPrime]
000002115442C1C1 <BytecodeArray[31]>[generating bytecode for function: Primes.getPrime]
000002115442D7B1 <BytecodeArray[14]>
With this CL, --print-bytecode flag will always output bytecode, but
detailed info about constant pool and handler table are still guarded.
Bug:NO
Change-Id: Ie03be74520f45659303d1658da5b2acc02cf1b36
Reviewed-on: https://chromium-review.googlesource.com/497808
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Cr-Commit-Position: refs/heads/master@{#45187}
This is the next in the series of simplifying the logic to collect feedback
in compare bytecode handlers. An earlier cl (
https://chromium-review.googlesource.com/c/483399/) modified StrictEquals
bytecode handler. This cl inlines the type feedback collection for the
Equalbytecode handler.
Bug: v8:4280
Change-Id: I36210a2412bb84a3fdb982aabccf8cdefe87e30e
Reviewed-on: https://chromium-review.googlesource.com/498447
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45183}
As a first step towards improving generator creation, create a builtin
that can do it without a call to the runtime. Thread that builtin
into the interpreter via an intrinsic.
BUG=v8:6352
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2861983002
Cr-Commit-Position: refs/heads/master@{#45145}
Removes the do-expression wrapping, modifies BytecodeGenerator change
to enter a class literal's block scope if needed.
This does not solve the actual bug in v8:6322, but helps mitigate it in
simple cases. The bug is caused by BytecodeGenerator not allocating a
large enough array of context registers to hold its entire stack,
allowing non-context registers to be overwritten during PushContext and
PopContext bytecodes.
Nevertheless, I like the idea of not depending on do-expressions when
possible, so I think it's worth doing anyways.
BUG=v8:6322
R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
Reviewed-on: https://chromium-review.googlesource.com/491074
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45110}
We only need to materialize the existing output register for a given
register transfer if it is in a different equivalence set, otherwise we
already have the value we want in the output register.
BUG=v8:4280
Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa
Reviewed-on: https://chromium-review.googlesource.com/493168
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45051}
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}
With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
ObjectLiteral flags.
Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
The feedback collection was decoupled from the actual comparison in the
compare bytecode handlers. This involves checks on the type of operands both
when collecting the feedback and when performing the operation. To avoid this
the type feedback is collected inline with the actual comparison.
This cl inlines the type feedback collection for the StrictEqual bytecode
handler. The other compare operations will be handled in subsequent cls.
Bug:
Change-Id: I429ed3c58b344c1c492e743c190bf16ab991ce6e
Reviewed-on: https://chromium-review.googlesource.com/483399
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44919}
This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.
Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.
Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.
This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.
BUG=chromium:709075
Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}
The AsyncGeneratorYield builtin just invoked the
AsyncGeneratorResolve() stub anyways, so this removes the middle-man.
Really minor refactoring, but clears out a bit of snapshot size and
another context index.
BUG=v8:5855
R=rmcilroy@chromium.org, bmeurer@chromium.org
Change-Id: I3385a5c5412e8d58493601874c2ad6b60e613012
Reviewed-on: https://chromium-review.googlesource.com/471913
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44820}
So that we can delete object properties without a runtime call.
The builtin implements a few fast paths (for now only deletion
of dictionary properties), and calls the runtime for all other
cases.
Review-Url: https://codereview.chromium.org/2810363003
Cr-Commit-Position: refs/heads/master@{#44740}
e3246ad69c
removed some redundancies in yield and yield*.
In particular:
- AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL
- Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate
BUG=v8:6187, v8:5855
R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org
Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c
Reviewed-on: https://chromium-review.googlesource.com/471806
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44649}
The BytecodePipeline is no longer used by any optimizers, so remove it and
connect the BytecodeArrayBuilder directly to the BytecodeWriter.
Also remove some functions from BytecodeNode which are no longer used.
BUG=v8:6194
Change-Id: Id2ec94ff1d4db41b108a778100459283fbb2256c
Reviewed-on: https://chromium-review.googlesource.com/471528
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44619}
This relands commit a79f903155.
Original change's description:
> [Interpreter] Unify approach to building interpreter handler and Turbofan stubs.
>
> Moves interpreter-generator.cc to a similar model of building handlers as
> Turbofan stubs elsewhere, to simplify moving code between stubs / builtins and
> bytecode handlers. This removes the "__" hack from the Interpreter generator
> code.
>
> Also make SetBytecodeOffset private to InterpreterAssembler and make
> LdaImmutable[Current]ContextSlot and Lda[Current]ContextSlot share
> handlers since they are identical.
>
> Change-Id: I9e91e7d37c2ea75513e4dcc3b95b4bb6517f83da
> Reviewed-on: https://chromium-review.googlesource.com/471987
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44534}
>
TBR=rmcilroy@chromium.org,jkummerow@chromium.org,machenbach@chromium.org,cbruni@chromium.org,leszeks@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
Change-Id: I282fe5582f681ccb0642537a70f89185558ee195
Reviewed-on: https://chromium-review.googlesource.com/474755
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44617}
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}
Move dead bytecode elimination from a seperate bytecode pipeline optimizer
into the BytecodeArrayWriter. This removes the last bytecode pipeline
optimizer, which means we can remove the Bytecode pipeline which,
which should increase compile speed.
BUG=v8:6194
Change-Id: I47fb3c3463b2b8a92e02cf7a6b608683fcfa5261
Reviewed-on: https://chromium-review.googlesource.com/471407
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44568}
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}
Moves the logic for eliding non-effectful accumulator load elision from the
peephole optimizer to the BytecodeArrayWriter.
BUG=v8:6194
Change-Id: I05fbe4ee8ac340e5c355285d0b47e4a9d52fd0a8
Reviewed-on: https://chromium-review.googlesource.com/469828
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44560}
This patch implements the runtime semantics of dynamic import.
We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.
d8 implements the embedder logic required to load and evaluate the modules.
The API is mostly implemented as specified.
BUG=8:5785
Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
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}
This reverts commit a79f903155.
Reason for revert: Need to revert:
https://chromium-review.googlesource.com/c/463287/
Original change's description:
> [Interpreter] Unify approach to building interpreter handler and Turbofan stubs.
>
> Moves interpreter-generator.cc to a similar model of building handlers as
> Turbofan stubs elsewhere, to simplify moving code between stubs / builtins and
> bytecode handlers. This removes the "__" hack from the Interpreter generator
> code.
>
> Also make SetBytecodeOffset private to InterpreterAssembler and make
> LdaImmutable[Current]ContextSlot and Lda[Current]ContextSlot share
> handlers since they are identical.
>
> Change-Id: I9e91e7d37c2ea75513e4dcc3b95b4bb6517f83da
> Reviewed-on: https://chromium-review.googlesource.com/471987
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44534}
TBR=rmcilroy@chromium.org,jkummerow@chromium.org,leszeks@chromium.org,ishell@chromium.org,cbruni@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I5c72a8a20ab6b8fd862427e1703c883fa484a2c1
Reviewed-on: https://chromium-review.googlesource.com/474745
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44547}
Moves interpreter-generator.cc to a similar model of building handlers as
Turbofan stubs elsewhere, to simplify moving code between stubs / builtins and
bytecode handlers. This removes the "__" hack from the Interpreter generator
code.
Also make SetBytecodeOffset private to InterpreterAssembler and make
LdaImmutable[Current]ContextSlot and Lda[Current]ContextSlot share
handlers since they are identical.
Change-Id: I9e91e7d37c2ea75513e4dcc3b95b4bb6517f83da
Reviewed-on: https://chromium-review.googlesource.com/471987
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44534}
Make sure that the current bytecode's size is taken into account when
updating the interrupt budget (on jumps and returns), so that jumps are
not "free" from an interrupt point of view.
Also clarifies, corrects and cleans up the interrupt budget update for
returns.
Bug: v8:6238
Change-Id: I1099d53a232fab4c1fcc91115baee610bfbce1d6
Reviewed-on: https://chromium-review.googlesource.com/472809
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44533}
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}
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
Previously landed as 4782bc0df8 / r44412.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44489}
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}
Rather than doing nop elision in the peephole optimizer, be smarter about
emitting nops for elided register transfers in the bytecode optimizer.
BUG=v8:6194
Change-Id: Ib1a7168a0d143e4f2da7c6d43080998793c30822
Reviewed-on: https://chromium-review.googlesource.com/468929
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44479}
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}
Moves the ToName elision out of the peephole optimizer and into the
BytecodeGenerator.
BUG=v8:6194
Change-Id: Ic355adbe21f967dc5d52babdd37100a260c62c26
Reviewed-on: https://chromium-review.googlesource.com/467466
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44427}
Reason for revert:
I think that this CL breaks chromium compilation on windows with clang (). All other CLs in the list looks trivial and don't change test/unittest/BUILD.gn.
[42456/47924] CXX obj/v8/test/unittests/unittests/value-serializer-unittest.obj
[42457/47924] LINK unittests.exe unittests.exe.pdb
FAILED: unittests.exe unittests.exe.pdb
E:/b/depot_tools/python276_bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./unittests.exe /PDB:./unittests.exe.pdb @./unittests.exe.rsp
bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::AddAllocationObserver(class v8::internal::AllocationObserver *)" (?AddAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)
slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: void __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::Add(class v8::internal::AllocationObserver * const &,class v8::internal::FreeStoreAllocationPolicy)" (?Add@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAAXAEBQEAVAllocationObserver@23@VFreeStoreAllocationPolicy@23@@Z)
bitmap-unittest.obj : error LNK2019: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z) referenced in function "public: virtual void __cdecl v8::internal::Space::RemoveAllocationObserver(class v8::internal::AllocationObserver *)" (?RemoveAllocationObserver@Space@internal@v8@@UEAAXPEAVAllocationObserver@23@@Z)
slot-set-unittest.obj : error LNK2001: unresolved external symbol "public: bool __cdecl v8::internal::List<class v8::internal::AllocationObserver *,class v8::internal::FreeStoreAllocationPolicy>::RemoveElement(class v8::internal::AllocationObserver * const &)" (?RemoveElement@?$List@PEAVAllocationObserver@internal@v8@@VFreeStoreAllocationPolicy@23@@internal@v8@@QEAA_NAEBQEAVAllocationObserver@23@@Z)
./unittests.exe : fatal error LNK1120: 2 unresolved externals
Original issue's description:
> [snapshot] Move builtins generation into mksnapshot
>
> and out of the main library. This saves about 5% of binary size
> (800KB on x64, 373KB on android_arm).
>
> Only the GN build is supported; the GYP build is maintained working
> but does not support the feature.
>
> BUG=v8:6055
> CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
>
> Review-Url: https://codereview.chromium.org/2760233005
> Cr-Commit-Position: refs/heads/master@{#44412}
> Committed: 4782bc0df8TBR=jgruber@chromium.org,rmcilroy@chromium.org,machenbach@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2803903002
Cr-Commit-Position: refs/heads/master@{#44422}
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}
and out of the main library. This saves about 5% of binary size
(800KB on x64, 373KB on android_arm).
Only the GN build is supported; the GYP build is maintained working
but does not support the feature.
BUG=v8:6055
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel;
Review-Url: https://codereview.chromium.org/2760233005
Cr-Commit-Position: refs/heads/master@{#44412}
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}
Check that a register used as a local is within the bytecode array's
local count.
BUG=chromium:706234
Change-Id: I51f6a0a8be065b93b9a4e1dca623e98c51685b51
Reviewed-on: https://chromium-review.googlesource.com/464768
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44308}
Add the source position to variables if they are parameters.
Collect type information for parameters and return values.
Index the types by their corresponding source position. For the
types of return values, use the function end as source position.
Sample output for a function with 2 parameters (at source
position 252 and 258, and function end at 443)
*************
Function: testFunction
252:
Object
number
string
number
258:
undefined
boolean
undefined
undefined
443:
Object
number
string
number
*************
BUG=v8:5933
Change-Id: I3b8749afcac706c1834146abf1b5b4a3fd130fb6
Reviewed-on: https://chromium-review.googlesource.com/461919
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44299}
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}
Compare bytecode handlers does several checks to collect feedback and
repeats these checks when actually performing the operation. This cl
changes it perform the actual comparison for smi / number along with
collecting feedback.
BUG=v8:4280
Change-Id: If0954b68dd232461e08e94a90ccc17604c235b27
Reviewed-on: https://chromium-review.googlesource.com/458420
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44216}
Previously we threw a generic error meesage on failing hole check for
accessing 'this'. But 'this' can be a hole only if the super() has not
been called so we change the error message.
BUG=v8:5957
Change-Id: I2f0e3d813f16919645d8a5efa7d26e73bd2d83fe
Reviewed-on: https://chromium-review.googlesource.com/459085
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44162}
If used, the TypeProfileSlot is always added as the first slot and its
index is constant. If other slots are added before the TypeProfileSlot,
this number changes.
BUG=v8:5933
Change-Id: I57bc6bea3c48804af28c2d1dafe6a52bdd7d12e3
Reviewed-on: https://chromium-review.googlesource.com/459511
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44149}
The former will handle stores to global variables, lets and undeclared
variables. The latter will handle named stores to explicit receiver.
BUG=chromium:576312, v8:5561
Change-Id: I335fa21db47c3d001da8cc79fa8cb6f8abcbb7e2
Reviewed-on: https://chromium-review.googlesource.com/458639
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44085}
When using --trace-ignition-codegen, the name for each bytecode handler is
missing. The reason is that we find the name of a bytecode by looking up the
code object entry in the interpreter's dispatch table, which is not yet
populated at this point.
BUG=
Review-Url: https://codereview.chromium.org/2771503004
Cr-Commit-Position: refs/heads/master@{#44068}
This CL also
1) turns (Add/Subtract)WithFeedbackStub into builtins
2) makes interpreter use BinaryOpAssembler directly
3) drops unused (Multipy/Divide/Modulus)WithFeedbackStubs
BUG=v8:6116
Change-Id: I994aba6442f173535c13dfbaaafae1033de3f2ce
Reviewed-on: https://chromium-review.googlesource.com/458438
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44042}
While the primary use-case for Suspend nodes is the Yield expression,
there are other uses as well: Await expressions, and the initial suspend
of Generators, which returns an object matching the Iterator protocol.
"Suspend" is a better representation of the spec text (closer
to the spec text for the values of [[GeneratorState]] and
[[AsyncGeneratorState]]), and can make it easier to understand the
meaning of what I had previously called Yield::is_normal() (now
Suspend::is_yield()).
Changes requested as part of https://chromium-review.googlesource.com/c/447117/
BUG=
R=neis@chromium.org, adamk@chromium.orgTBR=bmeurer@chromium.org, paul.lind@imgtec.com, joransiu@ca.ibm.com, weiliang.lin@intel.com
Change-Id: Ic6f15b04fff091c20f26526391b967287c06f6bf
Reviewed-on: https://chromium-review.googlesource.com/455583
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44038}
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}
Handle fall-off returns and returns inside try blocks.
Store the type-profile feedback slot on the FunctionLiteral
rather than on every return statement.
Next steps:
* Store entries in nexus that can be identified as 'return' (rather than parameter or assignment)
* Collect types for parameters and assignments
* Distinguish multiple parameters and assignments correctly
R=mstarzinger@chromium.org
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2764113002
Cr-Commit-Position: refs/heads/master@{#44014}
This frees up the InterpreterAssembler for no longer being linked
into the main library.
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2759093004
Cr-Commit-Position: refs/heads/master@{#43979}
Collect type information of return values.
Use *one* feedback slot per function for all its return
statements. For assignments, we currently use
several slots per function, because not all
assignments refer to the same variable.
Instead of the variable names, pass the
source location and print the function name.
Add an integration test for --type-profile that checks
for crashes.
Remove type feedback for assignments for now as it convolutes the output.
************ Function with 2 return statements ********
function testFunction(param, flag) {
// We want to test 2 different return positions in one function.
if (flag) {
var first_var = param;
return first_var;
}
var second_var = param;
return second_var;
}
testFunction({});
testFunction(123, true);
testFunction('hello');
testFunction(undefined);
*******************************************************
************* Sample Output ***************************
Function: testFunction
424: Object
374: number
424: string
424: undefined
*******************************************************
Missing work:
* Handle fall-off returns
* Collect types for parameters
* Remove duplicates from the list of collected types and use a common base class.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2755973002
Cr-Commit-Position: refs/heads/master@{#43956}
as InterpreterGenerator. This is in preparation for no longer including
the bytecode handler generation code in the main library.
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2765433003
Cr-Commit-Position: refs/heads/master@{#43949}
Default to the chromium-internal build config (instead of the more
permissive no_chromium_code config).
BUG=v8:5878
Review-Url: https://codereview.chromium.org/2758563002
Cr-Commit-Position: refs/heads/master@{#43909}
Reason for revert:
Doesn't seem to help with peak performance, and seems to hurt startup performance a bit, so reverting for now
Original issue's description:
> [ignition] Decrease code size multiplier to 24.
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2758503002
> Cr-Commit-Position: refs/heads/master@{#43861}
> Committed: b880309bc7TBR=rmcilroy@chromium.org,jarin@chromium.org,danno@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2751913007
Cr-Commit-Position: refs/heads/master@{#43891}
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}
These operations don't need the context, so no need to pass the context
to them. Also avoids the loading of context in the interpreter bytecode
handlers for StrictEqual and Typeof.
BUG=v8:5268,v8:5269
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2744173002
Cr-Commit-Position: refs/heads/master@{#43733}
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}
This inlines common LoadIC cases into the LdaNamedProperty bytecode
handler. Smi handlers resulting in constant/field loads for
monomorphic ICs omit frame construction. The same counts for the
polymorphic case as long as the target handler is in the first two
vector slots.
Other cases (megamorphic, uninitialized) call the new
LoadIC_Noninlined stub.
Local benchmarks show up to 6% improvement on Sunspider with --future.
BUG=v8:5917
Review-Url: https://codereview.chromium.org/2733563002
Cr-Commit-Position: refs/heads/master@{#43630}
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}
We don't need the JSStrictNotEqual operator in the compiler, because
this is never generated by the BytecodeGraphBuilder, and the code in
the AstGraphBuilder was dead code. Also remove the backing builtin
StrictNotEqual.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2727003006
Cr-Commit-Position: refs/heads/master@{#43594}
This is always the single variable declared in the catch scope.
BUG=
Change-Id: I05ccc48f57394268432c9b5b8c76f9db1b3b6312
Reviewed-on: https://chromium-review.googlesource.com/448041
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43571}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
The above intrinsic by now has to perform a check whether the prototype
of a derived constructor is actually a constructor function itself. This
is done as part of the {JSGetConstructorCall} operator. The intrinsic
should just reduce down to the operator to maintain correct semantics.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-696622
BUG=chromium:696622
Change-Id: Ia19c188f17ad16b12248db1f01a01b8d7258499b
Reviewed-on: https://chromium-review.googlesource.com/447716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43479}
FCG implemented an optimziation which could avoid emitting a memento if the
memento was only needed for transitioning. This optimization is currently
turned off as we always run with pretenuring. Since this optimization will not
be ported to Ignition for now, we just remove the support from FCG.
Disabling allocation site pretenuring will then not make FCG and Iginition
diverge in their behavior.
BUG=chromium:693413
Change-Id: I69aea73426fc69d48e1fe6ed13caaf28f9cfb32f
Reviewed-on: https://chromium-review.googlesource.com/445258
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43345}
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}
The bytecode generator did not necessarily know for which scope, and
thus language mode, it was generating code, because it only tracked
scopes that have a context. This led to wrong behavior in some
examples involving class expressions (which are always in strict
mode).
With this CL, the bytecode generator explicitly tracks the current
scope, independent of whether it has a context.
BUG=v8:5927
Change-Id: Ifa6b3ee5e13e07b63d00e74c7f557a328633c88b
Reviewed-on: https://chromium-review.googlesource.com/444785
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43300}
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}
Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.
After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.
Some highlights from the CL:
* Added methods to the CSA and InterpreterAssembler to efficiently store and
load Smis values and Smi interpreter registers on x64 without explicit
tagging/untagging.
* Created Variables for all of the interpreter-internal values that need to be
reloaded before bytecode dispatch at the end of an interpreter handler.
* The bytecode offset can be written out early in a handler by marking it
has having a call along it's critical path. By moving this early in a
handler, it becomes possible to use memory operands for pushes used to
marshall parameters when making calls.
Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
When --harmony-async-iteration is enabled, it is now possible to
use the for-await-of loop, which uses the Async Iteration protocol
rather than the ordinary ES6 Iteration protocol.
the Async-from-Sync Iterator object is not implemented in this CL,
and so for-await-of loops will abort execution if the iterated object
does not have a Symbol.asyncIterator() method. Async-from-Sync
Iterators are implemented seperately in https://codereview.chromium.org/2645313003/
BUG=v8:5855, v8:4483
R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org
Review-Url: https://codereview.chromium.org/2637403008
Cr-Commit-Position: refs/heads/master@{#43224}
Instead of calling the LoadGlobalIC stub, bytecode handlers now inline
logic for LoadGlobalIC. The LoadGlobalICData case takes a fast path
which omits name loading and frame construction.
BUG=v8:5917
Review-Url: https://codereview.chromium.org/2684973002
Cr-Commit-Position: refs/heads/master@{#43210}
These intrinsics are no longer required, but their runtime call pendants
are still in use. So remove support for those from all compilers.
BUG=v8:5049
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2694623002
Cr-Commit-Position: refs/heads/master@{#43131}
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}
The --ignition-filter hasn't worked properly for a while due to some functions
only being supported by Ignition. Remove it and add a --print-bytecode-filter
to allow the main use-case of limiting bytecode printing to a particular
function.
BUG=chromium:685476,v8:5203
Change-Id: Id41eeb3083ae9f713433d3a30227cd4c5d0d47dd
Reviewed-on: https://chromium-review.googlesource.com/441047
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43113}
Alternative approach to https://codereview.chromium.org/2667983004/, which
does not depend on implicit control flow changes from
https://codereview.chromium.org/2664083002
- Remove handling for `async function` from Parser::RewriteReturn(). This functionality
is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
is deferred until all finally blocks are evaluated fully.
- Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
generate return code using BuildAsyncReturn rather than BuildReturn.
- Parser has a new `NewReturnStatement()` helper which determines what type of return
statement to generate based on the type of function.
BUG=v8:5896, v8:4483
R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org
Review-Url: https://codereview.chromium.org/2685683002
Cr-Commit-Position: refs/heads/master@{#43104}
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}
Includes the port of these three builtins: FastNewStrictArguments,
FastNewSloppyArguments and FastNewRestParameter. Also inline
the implementation of these into the corresponding interpreter
byte codes.
BUG=v8:5269
LOG=N
R=ishell@chromium.org, rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2645743002
Cr-Commit-Position: refs/heads/master@{#43002}
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}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
branch based on whether the accumulator is true or false (no other
value allowed, and in fact TurboFan would blow up if you would pass
anything else, since Branch operator can only deal with Boolean).
So for either branch we know exactly the value of the accumulator,
and we can update the environment to this constant value instead.
This helps to avoid the useless bit materialization that currently
happens when || or && is being used in a value context.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win64_dbg
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2666283002
Cr-Original-Commit-Position: refs/heads/master@{#42843}
Committed: 158ac92871
Review-Url: https://codereview.chromium.org/2666283002
Cr-Commit-Position: refs/heads/master@{#42934}
Reason for revert:
Breaks win64 it seems.
Original issue's description:
> [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue.
>
> The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
> branch based on whether the accumulator is true or false (no other
> value allowed, and in fact TurboFan would blow up if you would pass
> anything else, since Branch operator can only deal with Boolean).
> So for either branch we know exactly the value of the accumulator,
> and we can update the environment to this constant value instead.
>
> This helps to avoid the useless bit materialization that currently
> happens when || or && is being used in a value context.
>
> R=jarin@chromium.org
> BUG=v8:5267
>
> Review-Url: https://codereview.chromium.org/2666283002
> Cr-Commit-Position: refs/heads/master@{#42843}
> Committed: 158ac92871TBR=jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2668933002
Cr-Commit-Position: refs/heads/master@{#42845}
The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
branch based on whether the accumulator is true or false (no other
value allowed, and in fact TurboFan would blow up if you would pass
anything else, since Branch operator can only deal with Boolean).
So for either branch we know exactly the value of the accumulator,
and we can update the environment to this constant value instead.
This helps to avoid the useless bit materialization that currently
happens when || or && is being used in a value context.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2666283002
Cr-Commit-Position: refs/heads/master@{#42843}
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}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
This makes sure all use-site of {ObjectLiteral::constant_properties} are
adapted to use the correct {BoilerplateDescription} type instead of just
the {FixedArray} base type.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2659603003
Cr-Commit-Position: refs/heads/master@{#42738}
Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.
We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587
Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
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}
[RELAND with one change: until literal arrays are rooted in the outer
feedback vector (coming in the next days), the runtime-scope.cc change
is held off.]
When a function is declared in global scope, the closure is created
by the DeclareGlobals runtime service. It needs a pointer to the
literals array, already allocated in the feedback vector. This
fixes a bug where it's behavior wasn't in sync with CreateClosure,
which accepts the literals from the vector.
This enables a follow-on performance improvement in the CompileLazy
builtin.
BUG=680637
Review-Url: https://codereview.chromium.org/2634283003
Cr-Commit-Position: refs/heads/master@{#42620}
The %_ValueOf intrinsic is not used anymore and the runtime call
%ValueOf will also disappear once all the self hosted builtins are
migrated.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2642303003
Cr-Commit-Position: refs/heads/master@{#42544}
The %_ClassOf intrinsic roughly corresponds to the deprecated ES5
[[Class]] internal property, and should not be used anymore ideally.
However since we still have quite a couple of uses of this intrinsic
in the self hosted JavaScript builtins, we would tank some builtins
like Map, Set, WeakMap, WeakSet, etc. quite significantly unless we
also support this intrinsic until the builtins are all migrated to
C++/CSA builtins.
R=yangguo@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2647833004
Cr-Commit-Position: refs/heads/master@{#42530}
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}
Due to outstanding performance issues, it's safer to revert these
changes.
Revert "PPC/s390: [TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "[TypeFeedbackVector] DeclareGlobals needs a literals array"
Revert "PPC/s390: [builtins] CompileLazy bailed out to the runtime entirely too often."
Revert "[builtins] CompileLazy bailed out to the runtime entirely too often."
Another CL is to follow that removes the main part of this work
(after that revert, performance regressions should disappear.
TBR=mstarzinger@chromium.org, leszeks@chromium.org, bmeurer@chromium.org
BUG=680637
Review-Url: https://codereview.chromium.org/2645543002
Cr-Commit-Position: refs/heads/master@{#42456}
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}
Collect Receiver feedback for abstract/strict equality in Ignition and
use it in TurboFan to optimize JSEqual and JSStrictEqual operations to
pointer equality instead of having to call Equal/StrictEqual builtins.
R=jarin@chromium.org
BUG=v8:5267,v8:5400
Review-Url: https://codereview.chromium.org/2639883002
Cr-Commit-Position: refs/heads/master@{#42435}
When a function is declared in global scope, the closure is created
by the DeclareGlobals runtime service. It needs a pointer to the
literals array, already allocated in the feedback vector. This
fixes a bug where it's behavior wasn't in sync with CreateClosure,
which accepts the literals from the vector.
This enables a follow-on performance improvement in the CompileLazy
builtin.
BUG=680637
Review-Url: https://codereview.chromium.org/2634283003
Cr-Commit-Position: refs/heads/master@{#42408}
The resume trampolin used to call the generator function with the context of the
last suspension rather than the closure's context. While that was fine for
Ignition, Turbofan got utterly confused. With this CL, the resume trampolin
always passes in the closure's context (like in the very first call of the
generator function). The generator function itself then restores its previously
current context by reading it from the generator object and doing a
PushContext.
BUG=chromium:681171
Review-Url: https://codereview.chromium.org/2639533002
Cr-Commit-Position: refs/heads/master@{#42407}
This makes sure all call sites allocating and installing the feedback
vector metadata are within the compilation pipeline and avoids spreading
them accross components.
R=leszeks@chromium.org
Review-Url: https://codereview.chromium.org/2631253002
Cr-Commit-Position: refs/heads/master@{#42399}
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2630343002
Cr-Original-Commit-Position: refs/heads/master@{#42381}
Committed: d611496b8e
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42394}
Reason for revert:
Seems to break modules-namespace2 on gcstress.
Original issue's description:
> [Parser] Introduce AstStringConstants to share constants across AstValueFactory
>
> Creates an AstStringConstants container which pre-initializes the
> string constants used by AstValueFactory. This ensures that all
> AstValueFactories will produce the same AstValue objects for constants,
> and so they can be used by the BytecodeGenerator without having to pass
> the AstValueFactory to it, enabling construction off-thread.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2630343002
> Cr-Commit-Position: refs/heads/master@{#42381}
> Committed: d611496b8eTBR=ahaas@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2638783002
Cr-Commit-Position: refs/heads/master@{#42382}
Creates an AstStringConstants container which pre-initializes the
string constants used by AstValueFactory. This ensures that all
AstValueFactories will produce the same AstValue objects for constants,
and so they can be used by the BytecodeGenerator without having to pass
the AstValueFactory to it, enabling construction off-thread.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2630343002
Cr-Commit-Position: refs/heads/master@{#42381}
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}
Since type feedback is stored as Smis, we can avoid a few shift
instructions per bytecode handler by performing type feedback updates
on Smis directly, rather than converting between Smi and Word32.
Review-Url: https://codereview.chromium.org/2624753002
Cr-Commit-Position: refs/heads/master@{#42236}
This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.
This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
Most notably, the interpreter now calls this stub instead of the
runtime.
BUG=
Review-Url: https://codereview.chromium.org/2619163004
Cr-Commit-Position: refs/heads/master@{#42218}
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}
Previously the message was "this is not defined" which is nonsensical.
BUG=v8:4407
Review-Url: https://codereview.chromium.org/2614053002
Cr-Commit-Position: refs/heads/master@{#42114}
This patch adds parsing of spread object property.
-- Changes ParsePropertyName to parse Token::ELLIPSIS.
-- Throws if rest is encountered by setting a pattern error.
-- Adds a new PropertyKind enum (SPREAD)
-- Adds a new ObjectLiteralProperty::kind (SPREAD)
-- Adds a new harmony-object-spread flag and protects the parser code
with it.
-- Adds a new runtime function called CopyDataProperties
-- Does not add any support for this feature in fullcodegen.
-- Ignition calls out to a runtime function CopyDataProperties to
perform spread operation.
-- Move FastAssign from builtins-objects.cc to objects.cc
-- Refactor Builtin_ObjectAssign to use SetOrCopyDataProperties
Object rest will be implemented in a follow on patch.
BUG=v8:5549
Review-Url: https://codereview.chromium.org/2606833002
Cr-Commit-Position: refs/heads/master@{#42102}
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}
This moves the initialization of [[HomeObject]] for constructors from
the %DefineClass runtime function into the bytecode generator, and
makes it conditional (resolving an old TODO). As part of this refactor,
avoid a load of "prototype" by returning the class prototype from
%DefineClass.
This is one of many steps in moving more of class definition into
bytecode.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2610683003
Cr-Commit-Position: refs/heads/master@{#42072}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Original-Commit-Position: refs/heads/master@{#42026}
Committed: b0e9116d59
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42042}
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/13358
Original issue's description:
> [Compiler] Track Ignition background compilation separately in RuntimeStats.
>
> Tracks background compilation of Ignition in a separate bucket from main thread
> compilation. Also add some more compilation buckets for functions which can take a
> significant proportion of compilation.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2577263002
> Cr-Commit-Position: refs/heads/master@{#42026}
> Committed: b0e9116d59TBR=jochen@chromium.org,cbruni@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2609773003
Cr-Commit-Position: refs/heads/master@{#42031}
Tracks background compilation of Ignition in a separate bucket from main thread
compilation. Also add some more compilation buckets for functions which can take a
significant proportion of compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2577263002
Cr-Commit-Position: refs/heads/master@{#42026}
Add machinery to Ignition and TurboFan to collect and consume
InternalizedString feedback for abstract and strict equality
comparisons. Here we can turn the comparison into a simple
pointer equality check.
R=jarin@chromium.org
BUG=v8:5786
Review-Url: https://codereview.chromium.org/2609013002
Cr-Commit-Position: refs/heads/master@{#42008}
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead.
This will allow IntepreterAssembler to use any other helper assembler.
TBR=rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2600183004
Cr-Commit-Position: refs/heads/master@{#41973}
The last remaining JS user of this in promise.js has recently been moved
to TF. The underlying FastObjectStub is still in use.
BUG=
Review-Url: https://codereview.chromium.org/2598973002
Cr-Commit-Position: refs/heads/master@{#41919}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Reason for revert:
speculative revert: https://codereview.chromium.org/2596013002/
Original issue's description:
> [regexp] Remove IsRegExp intrinsic
>
> The two remaining uses of this intrinsic in debug.js and mirrors.js now
> simply rely on the runtime function.
>
> BUG=v8:5339
>
> Review-Url: https://codereview.chromium.org/2591923003
> Cr-Commit-Position: refs/heads/master@{#41892}
> Committed: c9cb94a06fTBR=bmeurer@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2592383002
Cr-Commit-Position: refs/heads/master@{#41915}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
The two remaining uses of this intrinsic in debug.js and mirrors.js now
simply rely on the runtime function.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2591923003
Cr-Commit-Position: refs/heads/master@{#41892}
eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,
eval('var x; let y; ()=>y')
introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.
This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.
BUG=v8:5295, chromium:648719
Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
Encode the PropertyAttribute and whether the function
names must be set as a flag instead of setting two registers.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2586463002
Cr-Commit-Position: refs/heads/master@{#41812}
This is so that a NotSuperConstructor error is thrown before evaluating the
arguments to the super constructor. Besides updating the runtime function, a
new bytecode GetSuperConstructor is introduced.
BUG=v8:5336
Review-Url: https://codereview.chromium.org/2504553003
Cr-Commit-Position: refs/heads/master@{#41788}
Transform LdaNull/LdaUndefined followed by StrictEquality to TestNull/TestUndefined.
This would avoid a call to the compare IC. In the bytecode-graph builder these are
mapped to StrictEqual javascript operator. When reducing this operator, we already
optimize the cases for null/undefined.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2554723004
Cr-Commit-Position: refs/heads/master@{#41768}
This introduces an explicit struct for the communication channel between
the {ArrayLiteral} AST node and the corresponding runtime methods. Those
methods take a pair of {ElementsKind} as well as an array (can either be
a FixedArray or a FixedDoubleArray) of constant values.
For bonus points it also reduces the size of the involved heap object by
one word (i.e. length field of FixedArray not needed anymore).
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2581683003
Cr-Commit-Position: refs/heads/master@{#41752}
Adds assignment tracking to the bytecode analysis pass, and updates
bytecode graph builder to only create LoopExitValues for assigned
values.
Review-Url: https://codereview.chromium.org/2558093005
Cr-Commit-Position: refs/heads/master@{#41719}
Allocate the registers used as arguments to a call on-demand after visiting the
argument (or reciever). This means that the visited expression can use registers
that would otherwise have been allocated for arguments which haven't been
visited yet.
The reason for doing this is to avoid keeping things live in registers
unecessarily for chained function calls, which avoids a memory leak for
functions which chain a large number of calls with large temporary arguments /
recievers.
BUG=chromium:672027
Review-Url: https://codereview.chromium.org/2557173004
Cr-Commit-Position: refs/heads/master@{#41714}
This fixes a corner case where the {FastCloneShallowArrayStub} was used
for literals that are backed by a double backing store and would exceed
limits for new-space allocations on 32-bit architectures. The stub in
question does not support such literals, callers must use the runtime.
Note that this fix is for Ignition as well as FullCodeGenerator.
R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-672792
BUG=chromium:672792
Review-Url: https://codereview.chromium.org/2570843002
Cr-Commit-Position: refs/heads/master@{#41713}
Templatizes the AccumulatorUsage and OperandType for BytecodeNode creation and
BytecodeRegisterOptimizer::PrepareForBytecode. This allows the compiler to
statically know whether the bytecode being created accesses the accumulator
and what operand types need scaling, avoiding runtime checks in the code.
Also removes BytecodeNode::set_bytecode methods.
Review-Url: https://codereview.chromium.org/2542903003
Cr-Commit-Position: refs/heads/master@{#41706}
The evaluation order of this argument was accidentally changed when the
special-case was added for super calls with a final spread argument.
Review-Url: https://codereview.chromium.org/2563423002
Cr-Commit-Position: refs/heads/master@{#41633}
Introduces:
- a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
- a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
BUG=v8:4280
R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.orgTBR=rossberg@chromium.org
Review-Url: https://codereview.chromium.org/2557593004
Cr-Commit-Position: refs/heads/master@{#41555}
This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant.
BUG=v8:4199
Review-Url: https://codereview.chromium.org/2423053002
Cr-Commit-Position: refs/heads/master@{#41546}
This just calls into a runtime function for implementation currently.
Intermediate step in speeding up constructor calls containing a spread.
The NewWithSpread bytecode will probably end up having different arguments with future CLs - the constructor and the new.target should have their own regs. For now we are calling into the runtime function, so we need the regs together.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2541113004
Cr-Commit-Position: refs/heads/master@{#41542}
Equality with null/undefined is equivalent to a check on the undetectable bit
on the map of the object. This would be more efficient than performing the entire
comparison operation.
This cl introduces:
1. A new bytecode called TestUndetectable that checks if the object is null/undefined.
2. Updates peeophole optimizer to emit TestUndetectable when a LdaNull/Undefined
precedes equality check.
4. TestUndetectable is transformed to ObjectIsUndetectable operator when building
turbofan graph.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2547043002
Cr-Commit-Position: refs/heads/master@{#41514}
Reorders the jump bytecodes so that the majority of jump checks can be
implemented as range checks (rather than a list of comparisons that get
compiled to a bunch of jumps).
Review-Url: https://codereview.chromium.org/2537123002
Cr-Commit-Position: refs/heads/master@{#41498}
This allows us to optimise the bytecode liveness analysis to jump
directly to previously seen indices. The analysis is optimised to store
a stack of loop ends (JumpLoop bytecode indices), and iterate through
these indices directly rather than looping through the bytecode array to
find them.
Review-Url: https://codereview.chromium.org/2536653003
Cr-Commit-Position: refs/heads/master@{#41485}
1) CSA::Select() receives lambdas for generating true/false values.
The representation parameter made mandatory.
2) CSA::Select[Type]Constant() methods receive true/false nodes directly.
These methods are intended to be used for generating "selects" when
true/false values are already computed.
BUG=
Review-Url: https://codereview.chromium.org/2550683003
Cr-Commit-Position: refs/heads/master@{#41483}
1) CSA::StoreMap() added which triggers map-specific write barrier
unlike StoreObjectField() which triggers the full write barrier.
2) CSA::StoreMapNoWriteBarrier(object, map_root_index) added.
3) StoreMapNoWriteBarrier() is used for storing immortal immovable
maps since they don't require write barriers even for objects in
old space.
BUG=
Review-Url: https://codereview.chromium.org/2544793002
Cr-Commit-Position: refs/heads/master@{#41435}
The overload simply wraps creation of an IntPtrConstant and makes things more
readable.
Review-Url: https://codereview.chromium.org/2541843006
Cr-Commit-Position: refs/heads/master@{#41430}
Bonus: fixed a couple of places where 32-bit comparison was used.
BUG=
Review-Url: https://codereview.chromium.org/2543873003
Cr-Commit-Position: refs/heads/master@{#41417}
Unfortunately we have to split this up into two cases: those with exactly one spread argument as the final argument, and all others, due to any side-effects of evaluation being visible.
This is in preparation for a new bytecode which handles super calls.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2540593003
Cr-Commit-Position: refs/heads/master@{#41415}
Replaces the graph-based liveness analyzer in the bytecode graph builder
with an initial bytecode-based liveness analysis pass, which is added to
the existing loop extent analysis.
Now the StateValues in the graph have their inputs initialised to
optimized_out, rather than being modified after the graph is built.
Review-Url: https://codereview.chromium.org/2523893003
Cr-Commit-Position: refs/heads/master@{#41355}
Reason for revert:
Breaks the build:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14886
Original issue's description:
> [ignition/turbo] Perform liveness analysis on the bytecodes
>
> Replaces the graph-based liveness analyzer in the bytecode graph builder
> with an initial bytecode-based liveness analysis pass, which is added to
> the existing loop extent analysis.
>
> Now the StateValues in the graph have their inputs initialised to
> optimized_out, rather than being modified after the graph is built.
>
> Committed: https://crrev.com/1852300954c216c29cf93444430681d213e87925
> Cr-Commit-Position: refs/heads/master@{#41344}
TBR=jarin@chromium.org,rmcilroy@chromium.org,yangguo@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/2541443002
Cr-Commit-Position: refs/heads/master@{#41346}
Replaces the graph-based liveness analyzer in the bytecode graph builder
with an initial bytecode-based liveness analysis pass, which is added to
the existing loop extent analysis.
Now the StateValues in the graph have their inputs initialised to
optimized_out, rather than being modified after the graph is built.
Review-Url: https://codereview.chromium.org/2523893003
Cr-Commit-Position: refs/heads/master@{#41344}
TurboFan can indeed comsume NumberOrOddball feedback for abstract
relational comparisons, so we should just provide it from Ignition.
Drive-by-fix: Add a DCHECK to protect against abstract/strict equality
number comparison accidentially utilizing Oddball feedback.
BUG=v8:5267,v8:5400
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2518283002
Cr-Commit-Position: refs/heads/master@{#41166}
This pre-calculates and stores a vector of bytecode offsets, and then allows
one to iterate over it backwards. This could probably be adapted to a
bidirectional/random access iterator if we wanted to, but for now reverse
is all we need.
Review-Url: https://codereview.chromium.org/2518003002
Cr-Commit-Position: refs/heads/master@{#41153}
Refactors the bytecode array iterator to separate the iteration and the
bytecode parameter access, placing the latter into a separate
super-class. This will allow us to have other forms of access, e.g.
reverse iteration.
Review-Url: https://codereview.chromium.org/2519923002
Cr-Commit-Position: refs/heads/master@{#41152}
This renames the {operand_stack} field to {register_file}, to refelct
how said field is used on all {JSGeneratorObject} instances by now. This
is a pure refactoring CL, not changes in semantics.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2520913002
Cr-Commit-Position: refs/heads/master@{#41140}
Reason for revert:
Turbofan doesn't do proper ToNumber conversions on NumberOrOddball equality conversions.
BUG=v8:5660
Original issue's description:
> [Interpreter] Collect NumberOrOddball feedback in CompareOps.
>
> Collect feedback for oddballs in the interpreter compare operations handlers.
> This is important to ensure that we don't consider oddball comparisons as
> generic, which prevents optimization.
>
> BUG=chromium:660947
>
> Committed: https://crrev.com/721e74d9d942fd4f2e3392ea9626d9d404dbbbd0
> Cr-Commit-Position: refs/heads/master@{#41081}
TBR=bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:660947
Review-Url: https://codereview.chromium.org/2517133002
Cr-Commit-Position: refs/heads/master@{#41134}
Stepping in a generator now behaves similar to stepping inside an
async function. Stepping in or next at a yield expression will result in
a break inside the same generator when we return to the generator.
Behavior of step-out does not change.
R=jgruber@chromium.org, neis@chromium.org
BUG=chromium:496865
Review-Url: https://codereview.chromium.org/2519853002
Cr-Commit-Position: refs/heads/master@{#41132}
This is a next step towards removing names table from type feedback metadata.
BUG=chromium:576312, v8:5561
Review-Url: https://codereview.chromium.org/2507143003
Cr-Commit-Position: refs/heads/master@{#41106}
Add bytecode for defining data properties, which initially just calls the runtime function.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2510743002
Cr-Commit-Position: refs/heads/master@{#41101}
Ignition skipped collecting NumberOrOddball feedback if the right hand
side of a relational comparison is undefined, thus leading to a
deoptimization loop, because it reported Number feedback to TurboFan.
This was caught on 3d-raytrace test of SunSpider.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2513903002
Cr-Commit-Position: refs/heads/master@{#41094}
Collect feedback for oddballs in the interpreter compare operations handlers.
This is important to ensure that we don't consider oddball comparisons as
generic, which prevents optimization.
BUG=chromium:660947
Review-Url: https://codereview.chromium.org/2506283003
Cr-Commit-Position: refs/heads/master@{#41081}
Collect string feedback for compare operations. Without this,
functions which have a lot of string compare operations end up with
a high generic type percentage, and don't get optimized until very
late.
Currently TurboFan doesn't use this String feedback for compare
operations, but this could be done in future work if it is useful.
BUG=chromium:660947
Review-Url: https://codereview.chromium.org/2506013005
Cr-Commit-Position: refs/heads/master@{#41078}
The reasons are:
1) The names dictionaries in the feedback metadata seems to consume a lot of memory
and the idea didn't payoff.
2) The absence of a name parameter blocks data handlers support in LoadGlobalIC.
This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/).
BUG=chromium:576312, v8:5561
Review-Url: https://codereview.chromium.org/2510653002
Cr-Commit-Position: refs/heads/master@{#41046}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Original review: https://codereview.chromium.org/2498073002/
Review-Url: https://codereview.chromium.org/2502293002
Cr-Commit-Position: refs/heads/master@{#41028}