Otherwise there is a mismatch between eager parsing (where the reciever
is marked as MaybeAssigned) and lazy parsing (where the receiver is
deserialized and not marked MaybeAssigned) for arrow functions that
have an inner scope that calls eval.
BUG=chromium:989914
Change-Id: I8b8b78140858985a75a971b0e0a95bd61463457b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752851
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63206}
Moved code from the .cc file to the .h file, and added comments on important
methods.
There is still room for more cleanup / refactor, but it doesn't seem worth
it right now.
Bug: v8:9396
Change-Id: Id14d3ccaa853e0704732d468df504c379cd114b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748735
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63205}
The builtin in question was just tail-calling another existing builtin
anyways. Call sites of the above builtin are rare and only appear in
import wrappers, removing the unnecessary hop is more efficient.
R=thibaudm@chromium.org
Change-Id: I42286346119fc627f8b9ef23fb6e4b2da1da80de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752847
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63204}
Consistent naming, moved methods, etc.
There is a follow-up CL that moves code from this .cc to the private
part of the class in the .h file.
Bug: v8:9396
Change-Id: I9efac09baff7403bce1be9712c090d2ea70b60f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748734
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63203}
Since we can just use the lower bits, we can make the compressions no-ops.
As a note, they still change the representation so that the machine graph
verifier is happy.
X64's version of: https://chromium-review.googlesource.com/c/v8/v8/+/1751722
Bug: v8:7703
Change-Id: I728eb8b6b3953f053a7042797f3c498d13e3c948
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751729
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63202}
We cherish the ability to create a (for example) JSFunctionRef by
passing an object handle in phases of the compiler where we can't
inspect the handle to verify the instance type. A slight change to
constructor definitions of classes derived from ObjectRef allows us to
police this typing effectively.
Bug: v8:7790
Change-Id: I6ac8e4780d578e9c9cad80fdc87f399a92bc988d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751343
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63199}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/1749712 with a fix in
test-run-wasm-simd.cc to use base::Divide to work around C++ undefined
behavior when the denominator is 0.
Bug: v8:8460
Change-Id: Ia0a4ff621cccc6d9b7528717bf3fa7c79e42ba1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745819
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63198}
PagedSpace::Available() is mostly used for counters. One may expect
that it'd be constant time or bearly noticeable performance-wise, but
its cost is linear in the number of freelists and number of pages in
the freelists. Overall, d8 --prof showed that it has a important
runtime cost, and prevents freelists from scaling.
This CL makes this counter constant-time, and should improve
performances, even using with our current FreeList strategy
(FreeListLegacy).
Bug: v8:9329
Bug: v8:9093
Change-Id: I7682c5debc78498fe46e8dbce70b2fbd540b0fd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746473
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63197}
After compression, the values should only be used for their lower 32-bits (W registers).
This removes unnecessary 'ubfx' zero-extends.
The size of the embedded builtins is reduced by 0.2%.
This improves the ARES-6 by ~1.0%.
Bug: v8:7703
Change-Id: Ib9bd771b51e85717f415a346b37428f8821bf278
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751722
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63196}
When GC triggered while an exception is pending, a read to
memory that was no longer valid could happen while backtracking in the
regexp interpreter (introduced with commit fb0df2c).
This CL prevents this dirty read, that could have been a security issue.
Bug: chromium:992389, v8:9575
Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63195}
Port c4d31fea9e
Original Commit Message:
Stack limits were additionally maintained in pseudo-smi roots.
"Pseudo", because we stored the raw limit pointers there, just making
sure their values looked like smis by masking the least significant
bits.
This mechanism is no longer needed now that we can access the stack
limit external references as efficiently as the smi roots.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ida5c1fe10a494e9c6d665425bd464228978ecd1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752142
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63194}
Previously we only used this flag if asm_wasm instantiation failed, but
we should avoid trying asm_wasm again if we failed during the initial
parse/compile, in case we have to recompile due to bytecode flushing. This
also avoids issues if there is a tranisent reason we fail asm_wasm compilation
(e.g., stack overflow) and later recompilations succeed and cause
inconsistencies like in the linked bug.
BUG=chromium:991133
Change-Id: Id156efa9d8625ce3db2058cb279ea23aeb66052f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751784
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63192}
We were going for 64 bits to go back to 32 bits. For example,
TruncateInt64ToInt32(BitcastTaggedSignedToWord(ChangeCompressedToTagged(x)))
when that doesn't modify the value at all.
In order to keep the machine graph verifier happy two bitcast operations
were introduced.
As a drive-by nit cleanup, we were having two empty lines between some
functions implementations in machine-operator-reducer.cc.
Bug: v8:7703
Change-Id: Ifaa0d656010fe4f6f6f4581a2bb6633f060245b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749383
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63191}
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value.
However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_
and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a
unittest and the clusterfuzz script which highlighted the issue.
BUG=chromium:991133
Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63190}
This makes sure that the above predicate is independent of any global
process-wide state. The state of enabled features is now passed in
explicitly.
R=thibaudm@chromium.org
Change-Id: I5d44e2b0c0843d2e4f26aaf0d58d23afd5943726
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751348
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63188}
In generated code, we access fields inside IsolateData through the
root-register. On some platforms it is significantly cheaper to access
things that are close to the root-register value than things that are
located far away. The motivation for this CL was a 5% difference in
Octane/Mandreel scores between
// Part of the stack check.
cmpq rsp,[r13+0x9ea8]
and
cmpq rsp,[r13-0x30] // Mandreel score improved by 5%.
This moves the StackGuard up to fix Mandreel. As a drive-by, also move
two more fields up that are accessed by each CallCFunction.
Tbr: yangguo@chromium.org
Bug: v8:9534,chromium:993264
Change-Id: I5418b63d40274a138e285fa3c99b96e33a814fb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751345
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63187}
This reverts commit 47e077a28a.
Reason for revert: To avoid hard crashes on this CHECK until a proper
fix has landed.
Original change's description:
> [deoptimizer] Check whether output frames fit into stack space
>
> Change-Id: I7af0fe843f73b702b03ffa50ecca19aabd7583b8
> Bug: chromium:983850
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701858
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62738}
TBR=neis@chromium.org,sigurds@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:983850,chromium:987930,v8:9534
Change-Id: I1f1fe76c957e1f1cf2a117a5ddc7e62004497aeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741665
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63186}
We were doing the SmiCheck in Compressed, but then using the Tagged one to go
to Int32.
Bug: v8:7703
Change-Id: Ib65084590eb611f9abea9383ee307d21959caa21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748698
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63185}
Port 5b2ab2f6f7
Original Commit Message:
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.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I68a66054dc1422e7fc0598ef4d112a031ba94cc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1750223
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63184}
Stack limits were additionally maintained in pseudo-smi roots.
"Pseudo", because we stored the raw limit pointers there, just making
sure their values looked like smis by masking the least significant
bits.
This mechanism is no longer needed now that we can access the stack
limit external references as efficiently as the smi roots.
Bug: v8:9534
Change-Id: I37e78851c97aebc1012ea0e95075e56366a40a73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745339
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63183}
Previously these were called (real) stack limit on one end, (real)
jslimit on the other. With this CL we consistently use jslimit
everywhere.
Tbr: tebbi@chromium.org
Bug: v8:9534
Change-Id: I9f86ac113bb9682544c365d54f666c1312a073a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748738
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63179}
This allows us to keep v8 free of the dependency on the crash/base components.
Second half of the change: https://chromium-review.googlesource.com/c/chromium/src/+/1690003.
Bug: v8:9323
Change-Id: If35288e3916df951ae6e2ae39e1cb06fab5fbf8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699102
Commit-Queue: Irina Yatsenko <irinayat@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63177}
Also adds a NullContextScope for code which wants to ensure it is context
independent. Removes a workaround in V8ProfilerAgentImpl::startProfiling
which created a context due to CollectSourcePositions not being context
indpendent.
BUG=chromium:992063
Change-Id: I94c7eea6416dc64bc61fb8ff9cd945449a791a77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748693
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63176}
This requires a native context which might not be available when
collecting source positions, and errors are cleared in any case.
BUG=chromium:992063
Change-Id: Ie0b81f60debaaf9a7810a42f56de0c005a7fbe18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745338
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63175}
Create canonical ScopeInfos for the global this binding and empty function in
the read only space, rather than creating them during bootstrapping for each
native context. This saves some memory, and also means we don't need to access
the native context to get the global this binding in when deserializing a
scope info, which is important since parsing should be native context independent.
BUG=chromium:992063
Change-Id: I800f576e8e9b95d46e043cba0c1a03ae19a683c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748690
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63174}
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}
