Skip to content

V
V8
Switch branch/tag
  1. 07 Apr, 2022 1 commit
  3. 19 Oct, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Compact codegen for large character classes · 8bbb44e5
      Jakob Gruber authored 
      Large character classes may easily be created when unicode
properties (e.g.: /\p{L}/u and /\P{L}/u) are used - these are
expanded internally into character classes that consist of hundreds
of character ranges. Previously to this CL, we'd emit branching code
for each of these ranges, leading to very large regexp code objects.

This CL adds a new codegen mode for large character classes (where
'large' currently means > 16 ranges). Instead of emitting branching
code inline, the ranges are written into a ByteArray and we call into
the C function IsCharacterInRangeArray for the actual branching logic.
The ByteArray is smaller than emitted code and is deduplicated if the
same character class is matched repeatedly in the same pattern.

Note this mode is *not* implemented for the interpreter, since we
currently don't have a constant pool for irregexp bytecode, and thus
cannot reference ByteArrays.

Bug: v8:11069
Change-Id: I2d728e42d85114b796c637f791848731a104cd54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229377Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77463}
      8bbb44e5
  5. 12 Oct, 2021 1 commit
  7. 11 Oct, 2021 1 commit
  9. 06 Oct, 2021 2 commits
  11. 30 Sep, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Fix stack growth for global regexps · 3e3a027d
      Jakob Gruber authored 
      Irregexp reentrancy (crrev.com/c/3162604) introduced a bug for global
regexp execution in which each iteration would use a new stack region
(i.e. we forgot to pop the regexp stack pointer when starting a new
iteration).

This CL fixes that by popping the stack pointer on the loop backedge.

At a high level:

- Initialize the backtrack_stackpointer earlier and avoid clobbering
  it by setup code.
- Pop it on the loop backedge.
- Slightly refactor Push/Pop operations to avoid unneeded memory
  accesses.

Bug: v8:11382
Change-Id: Ibad6235767e110089a2b346034f923590b286a05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194251Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77158}
      3e3a027d
  13. 27 Sep, 2021 1 commit
  15. 23 Sep, 2021 2 commits
  17. 16 Aug, 2021 1 commit
  19. 24 Jun, 2021 3 commits
  21. 18 Jun, 2021 1 commit
  23. 07 Jun, 2021 1 commit
  25. 21 Apr, 2021 1 commit
  27. 08 Apr, 2021 1 commit
  29. 19 Mar, 2021 1 commit
    • Georgia Kouveli's avatar
      [cfi][arm64] Change InterpreterEnterBytecode use of LR for CFI. · ce85e66a
      Georgia Kouveli authored 
      This use of LR previously allowed overwriting it with arbitrary addresses
that aren't signed. Change this so we never return to an arbitrary LR.

Instead of loading the InterpreterTrampolineEntry address into LR directly,
use an ADR instruction to place into LR the address of a piece of code
that jumps to the InterpreterTrampolineEntry instead. This makes a difference
because BR is also constrained by BTI, whereas RET isn't.

An alternative would have been to `Call` instead of `Jump` to the target
bytecode and avoid the ADR instruction altogether, but I wanted to keep the
same behaviour with respect to the return stack that the existing code
exhibits.

Also add a comment to src/regexp/arm64/regexp-macro-assembler-arm64.cc for
a similar use of LR that should eventually be removed.

Bug: v8:10026
Change-Id: I24a13481f3fa416247dab8f9e5ae6f52f6b2ad42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2764761Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#73535}
      ce85e66a
  31. 17 Mar, 2021 2 commits
  33. 12 Jan, 2021 1 commit
  35. 16 Oct, 2020 1 commit
  37. 14 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Use experimental engine if backtrack limit exceeded · d4febb6b
      Martin Bidlingmaier authored 
      We fall back from irregexp to the experimental engine if a backtrack
limit is exceeded and the experimental engine can handle the regexp.
The feature can be turned on with a boolean flag, and an uint-valued
flag controls the default backtrack limit.  For regexps that are
constructed with an explicit backtrack limit (API,
%NewRegExpWithBacktrackLimit), we choose the lower of the explicit and
default backtrack limits.
The default backtrack limit does not apply to regexps that can't be
handled by the experimental engine, and for such regexps an explicitly
specified backtrack limit is handled as before by returning null if we
exceed it.

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
Bug: v8:10765
Change-Id: I580df79bd847520985b6c2c2159bc427315c89d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436341
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70500}
      d4febb6b
  39. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored 
      With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.

Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).

This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).

As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.

Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  41. 03 Jun, 2020 1 commit
  43. 21 Apr, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Hoist LoadCurrentCharacterImpl · 4536bb2e
      Iain Ireland authored 
      LoadCurrentCharacterImpl is implemented once in each of the eight
regexp-macro-assembler-<arch>.cc files. Aside from small differences
in comment wording, those eight implementations are identical. The
architecture-specific code for LoadCurrentCharacter is all in
LoadCurrentCharacterUnchecked.

This patch hoists the definition of LoadCurrentCharacterImpl into
NativeRegExpMacroAssembler and turns LoadCurrentCharacterUnchecked
into a virtual function.

Note: The arm64 version of LoadCurrentCharacterImpl contained the
following six-year-old comment, which I don't think is worth
preserving:

// TODO(pielan): Make sure long strings are caught before this, and
// not just asserted in debug mode.

R=jgruber@chromium.org

Bug: v8:10406
Change-Id: Ic81283ad3b618d6b06f4206fb77d30de617dccb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2140003
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67260}
      4536bb2e
  45. 17 Mar, 2020 1 commit
  47. 02 Mar, 2020 1 commit
  49. 28 Feb, 2020 1 commit
  51. 27 Feb, 2020 1 commit
    • Emanuel Ziegler's avatar
      [wasm] Save FP & PC when calling C functions · 6cd28b52
      Emanuel Ziegler authored 
      Added implementations for ia32, arm, arm64.

mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.

Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.

Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.

R=clemensb@chromium.org
R=petermarshall@chromium.org
R=jgruber@chromium.org

Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
      6cd28b52
  53. 19 Feb, 2020 1 commit
  55. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored 
      This is a reland of 137bfe47

Original change's description:
> [arm64] Protect return addresses stored on stack
> 
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack.  The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
> 
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
> 
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
> 
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

Bug: v8:10026
Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  57. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored 
      This reverts commit 137bfe47.

Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072

Original change's description:
> [arm64] Protect return addresses stored on stack
> 
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack.  The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
> 
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
> 
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
> 
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com

Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored 
      This change uses the Arm v8.3 pointer authentication instructions in
order to protect return addresses stored on the stack.  The generated
code signs the return address before storing on the stack and
authenticates it after loading it. This also changes the stack frame
iterator in order to authenticate stored return addresses and re-sign
them when needed, as well as the deoptimizer in order to sign saved
return addresses when creating new frames. This offers a level of
protection against ROP attacks.

This functionality is enabled with the v8_control_flow_integrity flag
that this CL introduces.

The code size effect of this change is small for Octane (up to 2% in
some cases but mostly much lower) and negligible for larger benchmarks,
however code size measurements are rather noisy. The performance impact
on current cores (where the instructions are NOPs) is single digit,
around 1-2% for ARES-6 and Octane, and tends to be smaller for big
cores than for little cores.

Bug: v8:10026
Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  59. 02 Jan, 2020 1 commit
  61. 14 Nov, 2019 1 commit
  63. 22 Oct, 2019 1 commit
  65. 21 Oct, 2019 1 commit
  67. 16 Sep, 2019 1 commit