1. 16 Aug, 2021 1 commit
  2. 24 Jun, 2021 3 commits
  3. 18 Jun, 2021 1 commit
  4. 07 Jun, 2021 1 commit
  5. 21 Apr, 2021 1 commit
  6. 08 Apr, 2021 1 commit
  7. 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
  8. 17 Mar, 2021 2 commits
  9. 12 Jan, 2021 1 commit
  10. 16 Oct, 2020 1 commit
  11. 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
  12. 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
  13. 03 Jun, 2020 1 commit
  14. 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
  15. 17 Mar, 2020 1 commit
  16. 02 Mar, 2020 1 commit
  17. 28 Feb, 2020 1 commit
  18. 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
  19. 19 Feb, 2020 1 commit
  20. 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
  21. 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
  22. 02 Jan, 2020 1 commit
  23. 14 Nov, 2019 1 commit
  24. 22 Oct, 2019 1 commit
  25. 21 Oct, 2019 1 commit
  26. 16 Sep, 2019 1 commit
  27. 04 Sep, 2019 1 commit
  28. 29 Aug, 2019 2 commits
  29. 13 Aug, 2019 1 commit
  30. 25 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [regexp] Use stricter bounds check to avoid additional iteration · f42b1a5d
      Seth Brenith authored
      The motivating example is JetStream 2's UniPoker test, which tests
      whether a sorted string of Unicode playing cards contains a five-card
      straight using a regular expression. In the top-level generated loop for
      this RegExp, we see this loop exit condition:
      
      00000350000C2067    27  83fffe         cmpl rdi,0xfe
      00000350000C206A    2a  0f8da8e40000   jge 00000350000D0518  <+0xe4d8>
      
      Meaning if the current position is pointing at the very last (16-bit)
      character, then we exit the loop. Otherwise we go on and try to find
      various matches starting at the current position. However, we can see
      in the original expression that any possible match is at least 10
      characters (5 astral-plane Unicode values), so we're wasting a lot of
      time attempting to find matches in cases where we're too close to the
      end of the string for any match to succeed.
      
      This example might be a bit contrived, but I expect that an improvement
      in this bounds check would help a larger family of regular expressions,
      where the minimum match length is large relative to the string being
      matched and we don't meet the other necessary criteria for fast Boyer-
      Moore lookahead.
      
      To get the desired bounds check in this case, this patch does the
      following:
      1. Compute accurate EatsAtLeast values for every node during the
         analysis phase. This could end up doing more work than the current
         implementation, but analysis already has to touch every node, so it
         seems like a cache-friendly time to compute these values. In some
         cases, this might be less total work than the current implementation,
         because the current implementation might recompute the same node
         multiple times.
      2. When emitting a quick check, use the EatsAtLeast value from the
         predecessor ChoiceNode for the bounds check.
      
      This improves the UniPoker score on my machine by about 4%, because it
      cuts the time spent checking for straights roughly in half, and checking
      for straights originally accounted for about 8% of the total time.
      
      Bug: v8:9305
      Change-Id: I110b190c2578f73b2263259d5aa5750e921b01be
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702125
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62919}
      f42b1a5d
  31. 24 Jul, 2019 1 commit
  32. 19 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      Revert "Reland "[regexp] Call the regexp interpreter without CEntry overhead"" · aa478cac
      Sathya Gunasekaran authored
      This reverts commit c2ee4a79.
      
      Reason for revert: webgl_conformance_tests deqp/data/gles2/shaders/conversions.html crashes on Android FYI Release (Nexus 9)
      See https://bugs.chromium.org/p/chromium/issues/detail?id=985624
      
      Original change's description:
      > Reland "[regexp] Call the regexp interpreter without CEntry overhead"
      >
      > This is a reland of d4d28b73
      >
      > Original change's description:
      > > [regexp] Call the regexp interpreter without CEntry overhead
      > >
      > > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
      > >
      > > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
      > >
      > > Bug: v8:8954
      > > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
      > > Commit-Queue: Patrick Thier <pthier@google.com>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#62753}
      >
      > Bug: v8:8954
      > Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Cr-Commit-Position: refs/heads/master@{#62794}
      
      TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:8954, chromium:985624
      Change-Id: I5bc2c397a09979f42f28670f80a5366f2a33d80f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709411
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62824}
      aa478cac
  33. 18 Jul, 2019 1 commit
    • Patrick Thier's avatar
      Reland "[regexp] Call the regexp interpreter without CEntry overhead" · c2ee4a79
      Patrick Thier authored
      This is a reland of d4d28b73
      
      Original change's description:
      > [regexp] Call the regexp interpreter without CEntry overhead
      > 
      > Previously all RegExp calls went through Runtime_RegExpExec when --regexp-interpret-all was set.
      > 
      > This CL avoids the runtime overhead by calling into the interpreter directly from the RegExpExec Builtin when the regular expression subject was already compiled to ByteCode (i.e. after the first call).
      > 
      > Bug: v8:8954
      > Change-Id: Iae9dfcef3370b772a05b2942305335d592f6f15a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698391
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62753}
      
      Bug: v8:8954
      Change-Id: I1f0b6de9c6da65bcb582ddb41a37419116a5c510
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706053Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Patrick Thier <pthier@google.com>
      Cr-Commit-Position: refs/heads/master@{#62794}
      c2ee4a79
  34. 17 Jul, 2019 2 commits