The BytecodeGraphBuilder still looks at the heap. This CL mostly
eliminates heap lookups for:
* CreateArrayLiteral
* CreateObjectLiteral
* CreateRegExpLiteral
What remains is the lookup embedded in the creation of a VectorSlotPair,
which will be addressed in a subsequent change.
Bug: v8:7790
Change-Id: I5e4167f5542b84ed3684ad61f3dd1ef8ad84c96b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745482
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63173}
This CL eliminates managed heap reads from the ByteCodeGraphBuilder
from constants. These reads and serializations are made at serialization
time.
Bug: v8:7790
Change-Id: I5c59ea1f097d11f48994f41ac296cfc64121db25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746477
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63169}
We were only considering eliminating Stores of size Tagged. There doesn't
appear to be a reason why. This CL enables store store elimination for all
sizes.
For example, in pointer compression, it means that Compressed values can
be targeted. In 32 bit versions, it means that doubles can now be targeted.
This is safe under the assumption that every byte of a JS object is only
ever accessed through one offset. For instance, byte 15 of a given object
may be accessed using a two-byte read at offset 14, or a four-byte read at
offset 12, but never both in the same program.
Change-Id: I865d412ed5b4db53a0154cf4da6303c407fdbda7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746469
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63168}
Port 0aa204febf
Original Commit Message:
This CL unifies how stack checks are handled in the Turbofan pipeline
across architectures, in preparation for properly handling stack
overflows caused by deoptimization in follow-up work. It will also
open up possibilities to simplify related logic.
How this used to work: JSStackCheck was lowered to a UintLessThan
with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
this node pattern was later recognized during instruction selection
and rewritten to dedicated operators. On other platforms, including
arm and arm64, special logic exists to avoid useless
register-to-register moves when accessing the sp.
This CL introduces a new StackPointerGreaterThan operator, which takes
the stack limit as its sole input. This is what JSStackCheck now lowers
to. This is threaded through to code generation, where we emit the
appropriate code (in the future, we will apply an additional offset to
the sp here).
In follow-up CLs, we can remove or replace remaining uses of
LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
the LoadStackPointer operator, related node matchers, related register
constraints, and the pseudo-smi stack limit roots.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I175c110d30190bb543001b6fa77cd65cf22e5874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748002
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63167}
Now that all uses of LoadStackPointer have been removed, this CL cleans
up related code:
- Removed LoadStackPointer.
- Removed ArchStackPointer.
- Removed IA32StackCheck.
- Removed X64StackCheck.
- Removed StackCheckMatcher.
All stack checks now follow a simple path without matchers or special
register constraints: they load the limit and pass it to
StackPointerGreaterThan, which is finally handled by code generation.
Bug: v8:9534
Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63166}
The matcher used to be needed to avoid first moving rsp to an
allocated register for LoadStackPointer. This is no longer the case
with the new stack check structure based on StackPointerGreaterThan.
This CL updates the wasm stack check and removes now-unneeded
matchers.
The generated stack check code remains unchanged from before:
// Load the stack limit through the instance then compare against rsp.
REX.W movq rcx,[rbp-0x10]
REX.W movq rcx,[rcx+0x2f]
REX.W cmpq rsp,[rcx]
// And on ia32:
mov ecx,[ebp-0x8]
mov ecx,[ecx+0x17]
cmp esp,[ecx]
Bug: v8:9534
Change-Id: I9240ad922d19d498a2661c143b12d629ac14d093
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748733
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63165}
This removes LoadStackPointer and its last remaining use in the
interpreter assembler.
Bug: v8:9534
Change-Id: I19aafb12c5fd50248841a3d92448e64243c723ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748729
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63164}
CSA's stack checks (in CodeStubAssembler::PerformStackCheck) were
previously carefully crafted to hit the stack check node pattern
matchers later on during instruction selection (see StackCheckMatcher).
This brittle mechanism is no longer needed now that stack checks use the
new StackPointerGreaterThan machine operator.
Bug: v8:9534
Change-Id: Idca169df1cadc6db237a8d36883ec1a79418f288
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748728
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63163}
We assume that during bootstrapping, we won't create script contexts.
This is wrong, since JavaScript code in extensions may introduce
let/const variables.
R=jgruber@chromium.org
Change-Id: I02595abdbb65f41faffc90bde142849bbde6b554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666994
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63161}
IsolateData guarantees a fixed root-relative offset for its contents,
thus allowing more efficient code generation for accesses to these
addresses. The stack limit, located within the StackGuard, is used by
all stack checks in CSA.
This CL moves the StackGuard inside IsolateData to make such efficient
loads of the limit possible.
Bug: v8:9595,v8:9534
Change-Id: I9abe26b88952709c88bf625cc6c028497815a58c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741648
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63160}
Turbofan applies the following optimization to external reference
loads on arm64 and x64: if the root-relative offset to an external
reference's address is known to be constant (and the root register has
been initialized), calculate the external reference as |kRootRegister
+ <offset>| instead of loading it from the external reference table.
There are two main cases to consider:
1. External references to arbitrary addresses in the native address
space, e.g. libc_memcpy. These kinds of external references have a
fixed address within the same running process, but may (and likely
will) change between processes (e.g.: mksnapshot and later chromium),
and the root-relative offset is different for each Isolate within the
same process.
These kinds of external references can be optimized as above when
*not* generating code which will later be serialized, and *not*
generating isolate-independent code.
2. External references to addresses within the fixed-size region of
the Isolate (essentially: within IsolateData). Since these move with
the Isolate, their root-relative offset is guaranteed to be constant
at all times.
The optimization can always be applied to these cases as long as the
root register has been initialized.
Prior to this CL, we only recognized and optimized for case 1. This CL
additionally adds support for 2.
An example of improved code generated due to this CL:
Before:
// r13 is the kRootRegister on x64.
// 0x3010 is the root-relative offset to Isolate::context_address.
leaq rdx, [r13+0x3010]
movq r8, [rdx]
After:
movq rdx, [r13+0x3010]
Bug: v8:9534
Change-Id: Idfcca751e98a56c0e5ead2c701c12a677df75399
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748727
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63158}
This adds two helper functions in code-generator-{ia32,x64}:
- HasAddressingMode: is the addressing mode not equal to kNone?
- HasRegisterInput: is the specified input in a register?
Bug: v8:9534
Change-Id: I690ee52e247b347a7ef5ba0c98bba47c321ca6b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748726
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63157}
This CL unifies how stack checks are handled in the Turbofan pipeline
across architectures, in preparation for properly handling stack
overflows caused by deoptimization in follow-up work. It will also
open up possibilities to simplify related logic.
How this used to work: JSStackCheck was lowered to a UintLessThan
with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
this node pattern was later recognized during instruction selection
and rewritten to dedicated operators. On other platforms, including
arm and arm64, special logic exists to avoid useless
register-to-register moves when accessing the sp.
This CL introduces a new StackPointerGreaterThan operator, which takes
the stack limit as its sole input. This is what JSStackCheck now lowers
to. This is threaded through to code generation, where we emit the
appropriate code (in the future, we will apply an additional offset to
the sp here).
In follow-up CLs, we can remove or replace remaining uses of
LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
the LoadStackPointer operator, related node matchers, related register
constraints, and the pseudo-smi stack limit roots.
Bug: v8:9534
Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63156}
We weren't fully using InsertChangeCompressedToTagged and similar, which
in turn made it so that we were using more NewNode. This CL unifies the
way that we generate the insertion of Change nodes regarding decompressions.
Dribe-by fix: make InsertChangeCompressedPointerToTaggedPointer actually
use Pointer.
Bug: v8:7703
Change-Id: I1d8835a54914cdab93f652ff17e39e8271a585df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741661
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63154}
The Osr context is a pointer, and we can make it clear in the Typer.
Known pitfall: If we have a context within a context, the innner context
pointer is typed as Any.
Change-Id: Ia4d7e43ef42ef03f835e4b71d32d117ae835feee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741659
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63153}
We have already parsed a function when we call CollectSourcePositions, so we
shouldn't update the parsing statistics again otherwise we will double-count.
Also, CollectSourcePositions needs to be made native-context independent, and
Blink's CountUsage counter requires a context to have been entered when it is
called and so isn't context independent.
BUG=chromium:992063
Change-Id: Idda50b98a8308f022cb90e1a18afb43982e95298
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746472
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63151}
This CL implements a naive tiering-up strategy where the interpreter
is used for the first execution for every regex, and the compiler is
used for every execution after that. The only exception is if a
global replace is being executed on a regex, we eagerly tier-up to
native code right away.
To use the tier-up logic --regexp-tier-up needs to be set. It is
currently disabled by default.
Bug v8:9566
Change-Id: Ib64ed77cbfcde10411161c0541dfa2501a0a93bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710661
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63150}
We might have to collect source positions for existing functions when we
start profiling, and doing so requires a context to be entered in V8. Ensure
we always enter a context by creating a temporary context and entering it before
starting profiling.
BUG=chromium:992063
Change-Id: I72b259a3ad31b712b0475f7729fb4ffdab5cdd96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745481
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63149}
This reverts commit d1a4706af9.
Reason for revert: Experiment over.
Original change's description:
> Reland "[ptr-compr][arm64] Temporarily enable pointer compression on arm64"
>
> This is a reland of f5611402f7
>
> Original change's description:
> > [ptr-compr][arm64] Temporarily enable pointer compression on arm64
> >
> > ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> > pointer compression in order to keep testing the other config.
> >
> > Commented out the 'extra' variant since it was crashing. Opened a bug
> > regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
> >
> > Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
> >
> > Bug: v8:7703
> > Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63019}
>
> Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
> Bug: v8:7703
> Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63043}
TBR=machenbach@chromium.org,tmrts@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7703
Change-Id: I86a801d44ad4ea14b1388ad8ca6109cc8a57a7d7
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746470
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63148}
This contains the following upstream commits:
486d3fe: Rename DEBUG to WASM_API_DEBUG
8d8e37d: Explicitly number wasm_valkind_t
299ebe0: Fix underlying types for enums
70be7c6: Fix test
Change-Id: I692fb6c909e5211920438740d2c57ea7ee74ab12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745483
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63147}
The BytecodeGraphBuilder still looks at the heap. This CL completely
eliminates heap lookups for:
* CreateBlockContext
* CreateFunctionContext
* CreateEvalContext
* CreateCatchContext
* CreateWithContext
Bug: v8:7790
Change-Id: I8b88215ba14a11955729b33bd0ee57219719666d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745484
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63146}
The operator== in RegisterBase only compares the reg_code. On arm64 we have
another 'base', CPURegister. Before this change, registers from different
classes but with the same register number would compare as equal.
For example, x30 == d30 would be true, which is incorrect.
Change-Id: I8f19139df3f041b07bfa0883ec5ca768ef540802
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745475
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com>
Cr-Commit-Position: refs/heads/master@{#63145}
Some of the Float(32|64) to CompressedSigned cases had their functions
defined already so they are virtually free to implement.
We are still missing the unsigned case so I am keeping the TODO.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: Ibf40d5948226fd48aebe7f8e257c117d6a5ad478
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708483
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63143}
- Adds regular native heap entries to the HeapObjectsMap.
- Adds a side map for keeping a mapping of native objects to their canonical
heap entry that they have been merged into.
Change-Id: Ida00628126ded1948ceb2a0cbe14da817af7f361
Bug: chromium:988350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720810
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63140}
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}
This is a reland of 1152445367
Original change's description:
> [wasm] Test concurrent code emission
>
> This extends the jump table stress test. Currently, we generate
> different thunks (on the main thread) and then concurrently update the
> jump table to jump to one of these thunks.
> With this CL, we also generate the thunks concurrently. So this also
> tests whether there is proper synchronization between code generation
> and executing it in another thread.
>
> R=ahaas@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:9477
> Change-Id: I3598329e37482ebd27a13acc752581c714226184
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735319
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63097}
Bug: v8:9477
Change-Id: Iac696f1ff3cd5209231a8dd8d1500cf77c2777b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739370
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63138}
This adds some documentation why concurrently emitting code, patching
the jump table, and executing the jump table is safe.
R=ahaas@chromium.org
CC=mstarzinger@chromium.org, joey.gouly@arm.com
Bug: v8:9477
Change-Id: Ibe295d538a1a330c6b1d94eb1f514d1078020754
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738856
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63137}
Since the same value is also returned in 'result' field it is still populated in accord with 'returnByValue' parameter. This behavior is consistent with 'evaluate'.
R=dgozman@chromium.org, lushnikov@chromium.org
Bug: v8:9509
Change-Id: I9f72682f87492ce5cd0759dce75ab3d75a5fe31c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1707331
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yury Semikhatsky <yurys@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63134}
This reverts commit e2f98ec22c.
Reason for revert: Caused performance regression in ArrayLiteralInitialSpreadSmallHoley.
Original change's description:
> Use list of invalidated objects for old-to-new refs
>
> Instead of inserting "deletion" entries into the store buffer, keep
> a list of invalidated objects to filter out invalid old-to-new slots.
>
> The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
>
> Bug: v8:9454
> Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63087}
TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9454
Change-Id: I328b9f72df45fc9570d4a4d1b5389eac010638c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743970
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63131}
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}
If the function has been uncompiled (bytecode flushed) it will have lost any preparsed data.
When we recompile the outer function we will regenerate this PreParseData but it wasn't
being reattached to the inner function. This CL fixes this by checking for this case in
Compiler::GetSharedFunctionInfo and creating a new NewUncompiledDataWithPreparseData to
attach to the inner function.
BUG=v8:9479
Change-Id: I5c0fc8251006f8f5c7c7f5f9dd17b2ecc671b672
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741655
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63128}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
This CL changes the dispatch technique in the regex interpreter to
token-threaded dispatch, if computed gotos are supported by the
compiler. Otherwise old switch-based dispatch is still used
(e.g. for MSVC).
With computed gotos, less jumps will be emitted (no extra jump to
single branch point/begin of switch) and branch prediction will
be better because of no single branch point.
This CL improves performance on the RexBench Benchmark suite by ~10%.
Bug: v8:9575
Change-Id: I585ad824ff1cc595a5dfa8831ad66d6810d0119b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733073
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Patrick Thier <pthier@google.com>
Cr-Commit-Position: refs/heads/master@{#63126}
With lazy feedback allocation, we don't have feedback vectors when function
starts executing. If we mark the function on the first execution we would
be missing feedback for the initial part of the function and hence the
optimized code will not be useful.
This cl resets the optimization markers on OSR if the invocation count of
the function is less than 1. We may still do wasted optimizations if the
function is hot enough for optimizing but not for OSRing. In the long term
we may want to fix it differently. This fix covers the most common cases
in benchmarks.
Bug: chromium:987523
Change-Id: I1cfe82e6b9f95278b77c99b77d4b981828b5c0ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739373
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63124}
