Skip to content

V
V8
Switch branch/tag
  1. 12 Aug, 2019 18 commits
    • Milad Farazmand's avatar
      PPC/s390: [compiler] Refactor stack check handling · f7f370d2
      Milad Farazmand authored 
      Port 0aa204fe

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/+/1748002Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63167}
      f7f370d2
    • Jakob Gruber's avatar
      [compiler] Remove LoadStackPointer and related machinery · 5b2ab2f6
      Jakob Gruber authored 
      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: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63166}
      5b2ab2f6
    • Jakob Gruber's avatar
      [wasm] Update the stack check and remove WasmStackCheckMatcher · 376c7b61
      Jakob Gruber authored 
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63165}
      376c7b61
    • Jakob Gruber's avatar
      [interpreter,compiler] Remove CodeAssembler::LoadStackPointer · 56a6f0a1
      Jakob Gruber authored 
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63164}
      56a6f0a1
    • Jakob Gruber's avatar
      [compiler] Use StackPointerGreaterThan in CSA stack checks · 1e2ca0ca
      Jakob Gruber authored 
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63163}
      1e2ca0ca
    • Jakob Kummerow's avatar
      [wasm-c-api] Roll 8f25c3f: Get rid of massive overloading · 961c0280
      Jakob Kummerow authored 
      Change-Id: I144217abfdcb16e4b9e90e5729fe0aa389945dfb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748691Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63162}
      961c0280
    • Yang Guo's avatar
      Remove bogus assertion for script contexts. · 2f0e566c
      Yang Guo authored 
      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: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63161}
      2f0e566c
    • Jakob Gruber's avatar
      [isolate-data] Move the StackGuard to IsolateData · ef24a565
      Jakob Gruber authored 
      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/+/1741648Reviewed-by: 's avatarJakob 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}
      ef24a565
    • Yang Guo's avatar
      Use relative paths to OWNERS files · 04a6f872
      Yang Guo authored 
      R=machenbach@chromium.org

Bug: chromium:992584
Change-Id: I301013731a502689f2edd5c90e5e7bf2136198c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745337Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63159}
      04a6f872
    • Jakob Gruber's avatar
      [compiler] Widen optimization for external reference loads · 33e1a6e9
      Jakob Gruber authored 
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63158}
      33e1a6e9
    • Jakob Gruber's avatar
      [compiler] Add helper functions HasAddressingMode, HasRegisterInput · 54eca658
      Jakob Gruber authored 
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63157}
      54eca658
    • Jakob Gruber's avatar
      [compiler] Refactor stack check handling · 0aa204fe
      Jakob Gruber authored 
      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/+/1738863Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63156}
      0aa204fe
    • Mathias Bynens's avatar
      Roll Test262 · 408bafcb
      Mathias Bynens authored 
      Bug: v8:7834
Change-Id: I23d8d6f4b2d00f82f11615c5a17d29b24fdf3175
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748730
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63155}
      408bafcb
    • Santiago Aboy Solanes's avatar
      [ptr-compr][turbofan][cleanup] Make use of InsertChange functions · 53f6e02a
      Santiago Aboy Solanes authored 
      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/+/1741661Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63154}
      53f6e02a
    • Santiago Aboy Solanes's avatar
      [turbofan] Better typing of OSR context pointer · b597d6fa
      Santiago Aboy Solanes authored 
      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/+/1741659Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63153}
      b597d6fa
    • Tobias Tebbi's avatar
      [build] disable unittests failing on Win64 release · bc68618c
      Tobias Tebbi authored 
      Bug: chromium:992783
Change-Id: I54ac01dfaa6717a2600cf40af95d6e74872ad2b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748731Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63152}
      bc68618c
    • Ross McIlroy's avatar
      [Parsing] Avoid updating parsing stats in CollectSourcePositions. · 585ad977
      Ross McIlroy authored 
      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: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63151}
      585ad977
    • Ana Peško's avatar
      [regexp] Naive tiering-up · 71acda22
      Ana Peško authored 
      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/+/1710661Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ana Pesko <anapesko@google.com>
Cr-Commit-Position: refs/heads/master@{#63150}
      71acda22
  3. 09 Aug, 2019 16 commits
  5. 08 Aug, 2019 6 commits