It had essentially become a synonym for BytecodeArrayAccessor.
This removes the BytecodeArrayIterator class and renames
BytecodeArrayAccessor to BytecodeArrayIterator.
Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73005}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.
Torque compiler changes:
- Fix an issue where the parser created constexpr types for classes
based on the class name rather than the `generates` clause. This meant
that generated accessors referred to the imaginary type HashTable
rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
implement Torque macros. Maybe we'll need it eventually, but we don't
right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
Instead, emit a member function `SomeFieldOffset()` which fetches the
slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
complex length expressions. It fetches the slice for the last field
and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.
With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:
1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
and use them
3. Get rid of the FixedArray-style get and set accessors; use
TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
unnecessary `length` field
After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.
Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
Fix super calls so that arguments are evaluated before the
super constructor is checked to be in fact a constructor.
A new bytecode is introduced to split the IsConstructor check
out from the current GetSuperConstructor bytecode.
Bug: v8:10111
Change-Id: I3af99e32a34d99493806bb01b547d6f671cdc9de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493077
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70881}
This is the first step in a series of CLs. The goal is to make
super property access faster.
Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing
This CL:
- Add bytecode LdaNamedPropertyFromSuper
- IGNITION_HANDLER just calls Runtime::LoadFromSuper
- JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node
with a runtime call to Runtime::LoadFromSuper
Bug: v8:9237
Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69604}
Now that it is implicit in function entry and loop iteration, there is
no need for an explicit bytecode.
Also updated tests that used explicit bytecodes.
Bug: v8:10149, v8:9960
Change-Id: I3ca582f276829bd54feb35e6d4ea656a32efbd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093507
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66811}
Since now the IterationBody StackChecks are implicit within JumpLoops,
we are able to eagerly deopt in them. If we do that, whenever we advance
to the next bytecode we don't have to advance to the next literal
bytecode, but instead "advance" in the sense of doing the JumpLoop.
Adding tests that test this advancing for wide and extra wide JumpLoops.
Also, marking JumpLoop as needing source positions since now it has
the ability of causing an interrupt.
Bug: v8:10149, v8:9960
Fixes: v8:10149
Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66809}
The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).
However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.
Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.
Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).
Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
Add support for internalizing an AstValueFactory using the off-thread
factory. Includes adding ConsString support to OffThreadFactory.
This introduces a Handle union wrapper, which is used in locations that
can store a Handle or an OffThreadHandle. This is used in this patch for
the internalized "string" field of AST strings, and will be able to be
used for other similar fields in other classes (e.g. the ScopeInfo
handle in Scope, object boilerplate descriptor handles, the inferred
name handle on FunctionLiterals, etc.). It has a Factory-templated
getter which returns the appropriate handle for the factory, and a
debug-only tag to make sure the right getter is used at runtime. This
union wrapper currently decomposes implicitly to a Handle if the getter
is not called, to minimise code changes, but this implicit conversion
will likely be removed for clarity.
Bug: chromium:1011762
Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65816}
This is a reland of 8b89a7c32d
Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
1c8981e3f4).
Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}
Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
This reverts commit 8b89a7c32d.
Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}
TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.
Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
This is the first in a series of changes to reduce the number of
bytecodes generated for the iteration protocol based operations.
The GetIterator bytecode introduced in this change currently loads the
@@iterator symbol from an object that was previously done using the
LdaNamedProperty bytecode. This change uses builtin-based mechanism
that would be extended to perform additional operations in the future
on absorbing the bytecodes associated with the GetIterator operation
from the iteration protocol.
Bug: v8:9489
Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63139}
Cleans up a plethora of JumpIfUndefined().JumpIfNull()
occurances by introducing a new JumpIfUndefinedOrNull
bytecode.
Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63130}
This in in preparation for generic (off-heap/on-heap) bytecode
array accessor.
Bug: v8:7790
Change-Id: Ib419831ba1db95ab938179723ef5f130f01ae0d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1635895
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62222}
This CL was generated by an automatic clang AST rewriter using this
matcher expression:
callExpr(
callee(
cxxMethodDecl(
hasName("operator->"),
ofClass(isSameOrDerivedFrom("v8::internal::Object"))
)
),
argumentCountIs(1)
)
The "->" at the expression location was then rewritten to ".".
R=jkummerow@chromium.orgTBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org
Bug: v8:9183, v8:3770
No-Try: true
No-Tree-Checks: true
Change-Id: I0a7ecabdeafe51d0cf427f5280af0c7cab96869e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61764}
The original was reverted for breaking webkit layout tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
It also caused the following clusterfuzz failures:
chromium:935832
This was a correctness bug due to not properly handling the case of arrays with prototypes other
than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
both in access-assembler and in Turbofan.
chromium:935932
This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
debug builds but in release could show up in different places. This is the bug that caused the
webkit layout test failure that led to the revert.
Both bugs are fixed by in CL, and tests are added for those cases.
Bug: v8:8733, chromium:935932, chromium:935832
Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
Reviewed-on: https://chromium-review.googlesource.com/c/1493132
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59958}
This is a reland of 35269f77f8
Switches on an expression that unconditionally throws would have all their
case statements dead, causing a DCHECK error in the SwitchBuilder. This
fixes up the DCHECK to allow dead labels.
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org
Bug: chromium:934166
Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
Reviewed-on: https://chromium-review.googlesource.com/c/1494535
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59948}
This reverts commit 35269f77f8.
Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792
Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}
TBR=rmcilroy@chromium.org,leszeks@chromium.org
Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:934166
Reviewed-on: https://chromium-review.googlesource.com/c/1494534
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59947}
BytecodeLabels for forward jumps may create a dead basic block if their
corresponding jump was elided (due to it dead code elimination). We can
avoid generating such dead basic blocks by skipping the label bind when
no corresponding jump has been observed. This works because all jumps
except JumpLoop are forward jumps, so we only have to special case one
Bind for loop headers to bind unconditionally.
Since Binds are now conditional on a jump existing, we can no longer rely
on using Bind to get the current offset (e.g. at the beginning of a try
block). Instead, we now expose the current offset in the bytecode array
writer. Conveniently, this means that we can be a bit smarter about basic
blocks around these statements.
As a drive-by, remove the unused Bind(target,label) function.
Bug: chromium:934166
Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
Reviewed-on: https://chromium-review.googlesource.com/c/1488763
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59942}
This reverts commit 32fc0acfef.
Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
layout test breakage:
https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html
There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused.
Original change's description:
> Optimize `in` operator
>
> This change implements optimizations for the `in` operator for packed array
> elements and object properties. It adds a new feedback slot kind and an IC
> path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
> feedback to optimize based on the maps and keys.
>
> For more details see:
> https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
>
> This can provide 10x performance improvements of on loops of the form:
>
> for (let i = 0; i < ary.length; ++i) {
> if (i in ary) {
> ...
> }
> }
>
>
> Bug: v8:8733
> Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
> Reviewed-on: https://chromium-review.googlesource.com/c/1432598
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Matt Gardner <magardn@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#59843}
TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com
Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8733
Reviewed-on: https://chromium-review.googlesource.com/c/1488761
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59857}
This change implements optimizations for the `in` operator for packed array
elements and object properties. It adds a new feedback slot kind and an IC
path similar to KeyedLoadIC for handling the lookups. TurboFan uses the
feedback to optimize based on the maps and keys.
For more details see:
https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig
This can provide 10x performance improvements of on loops of the form:
for (let i = 0; i < ary.length; ++i) {
if (i in ary) {
...
}
}
Bug: v8:8733
Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8
Reviewed-on: https://chromium-review.googlesource.com/c/1432598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59843}
This takes heap-inl.h out of the "Giant Include Cluster".
Naturally, that means adding a bunch of explicit includes
in a bunch of places that relied on transitively including
them before.
As of this patch, no header file outside src/heap/ includes
heap-inl.h.
Bug: v8:8562,v8:8499
Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4
Reviewed-on: https://chromium-review.googlesource.com/c/1459659
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59617}
As opposed to the register.
For subtle reasons, this fixes a deoptimizer bug with handling return
values in lazy deopt. Since the return values can now only overwrite
the accumulator, there is no danger of overwriting a captured object
that might be later used (since there is no "later").
Bug: chromium:902608
Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
Reviewed-on: https://chromium-review.googlesource.com/c/1325901
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57349}
This is a reland of eccf186749
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
This reverts commit eccf186749.
Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com
Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8072
Reviewed-on: https://chromium-review.googlesource.com/1245421
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56232}
Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
for one-shot property loads and stores. This CL replaces the runtime
calls with new bytecodes for named property load stores in one-shot code.
the runtime calls needed extra set of consecutive registers and
additional move instructions. This increased the size of
bytecode-array and possibly extended the life time of objects.
By replacing them with NoFeedback bytecodes we avoid these issues.
Bug: v8:8072
Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
Reviewed-on: https://chromium-review.googlesource.com/1196725
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#56211}
We do not have to collect feedback for function calls in one-shot code.
This CL avoids allocating CallICslots for each function call by
emitting CallNoFeedback bytecodes. We save one CallICSlot (two entries
in feedback vector) per function call in One-shot.
Bug: v8:8072
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ic2580e5972acd5124c2e71d540985736ce797fe8
Reviewed-on: https://chromium-review.googlesource.com/1178051
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55951}
This is a reland of 1c48d52bb1.
It turned out that IterableToList doesn't always behave according to
the ES operation with the same name. Specifically, it allows holey arrays
to take its fast path, which produces an output array with holes where
actually "undefined" elements should appear.
This CL changes the version of IterableToList that is used for spreads
(IterableToListWithSymbolLookup) such that holey arrays take the slow path.
It also includes tests for such situations.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
Bug: v8:7980
Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201882
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
This reverts commit 1c48d52bb1.
Reason for revert: Clusterfuzz found something.
Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}
TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com
Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.
The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.
The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
As discussed in
https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
this CL introduces a new bytecode (CloneObject), and a new IC type.
In this prototype implementation, the type feedback looks like the
following:
Uninitialized case:
{ uninitialized_sentinel, uninitialized_sentinel }
Monomorphic case:
{ weak 'source' map, strong 'result' map }
Polymorphic case:
{ WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
Megamorphic case:
{ megamorphic_sentinel, cleared_Value }
In the fast case, Object cloning is done by allocating an object with
the saved result map, and a shallow clone of the fast properties from
the source object, as well as cloned fast elements from the source object.
If at any point the fast case can't be taken, the IC transitions to the
slow case and remains there.
This prototype CL does not include any TurboFan optimization, and the
CloneObject operation is merely reduced to a stub call.
It may still be possible to get some further improvements by somehow
incorporating compile-time boilerplate elements into the cloned object,
or simplifying how the boilerplate elements are inserted into the
object.
In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
BUG=v8:7611
Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
Reviewed-on: https://chromium-review.googlesource.com/1127472
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54595}
Return the raw Object* when accessing the constant pool of bytecode
with the bytecode array accessor, to avoid needing an isolate there.
If the returned value needs to be a handle, we create the handle
later.
Bug: v8:7786
Change-Id: Ifeac2a06f0383230bf7e9bfc1b751d9750ecfb51
Reviewed-on: https://chromium-review.googlesource.com/1102334
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53784}
Instead rely on the scope info containing the name as well.
Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab
Reviewed-on: https://chromium-review.googlesource.com/1042567
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52983}
There are likely cleanups that can be done after this CL:
- context-related functions in the interpreter and compiler take ScopeInfo as
well as ScopeType and slot-count as input. The latter 2 should be directly
derived from the former. We should be able to drop FunctionContextParameters.
- ContextExtension is probably not needed anymore, since we now always have the
correct scope_info directly in the SCOPE_INFO_INDEX slot.
Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67
Reviewed-on: https://chromium-review.googlesource.com/785151
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52952}
This reverts commit 2df5e7a7b6.
Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
Original change's description:
> [parser] Slice the source string where possible
>
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
>
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
>
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}
TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
When internalizing string literals (for quoted strings or property names),
try to create a sliced string of the source string rather than allocating
a copy of the bytes.
This will not work for string literals that contain escapes (e.g. unicode
escapes), and currently does not support two-byte strings.
Bug: chromium:818642
Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
Reviewed-on: https://chromium-review.googlesource.com/1010282
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52898}
Several functions on Array.prototype incorrectly threw a TypeError just
because their receiver was sealed or frozen.
Bug: v8:7677
Change-Id: I4ec38bfbf468f9bd676f1c0b341c8a50cf814f15
Reviewed-on: https://chromium-review.googlesource.com/1021870
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52718}
There are various situations where we explicitly compare a SMI against
another SMI (e.g., BuildIndexedJump). This is also a common pattern for
generated code (e.g., comparing a loop variable with an integer). Instead
of using the generic equality/strict-equality stub for this, which is
expensive, this CL offers a simple comparison stub, repurposing the
TestEqualStrictNoFeedback bytecode to TestReferenceEqual
Bug: v8:5310
Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5
Reviewed-on: https://chromium-review.googlesource.com/1007542
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Christian O. Andersson <cricke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52655}
