1. 14 Jan, 2021 1 commit
  2. 13 Jan, 2021 2 commits
  3. 03 Jun, 2020 1 commit
  4. 11 May, 2020 1 commit
  5. 02 Mar, 2020 1 commit
  6. 01 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[regexp] Bytecode peephole optimization" · 282a74c7
      Jakob Gruber authored
      This is a reland of 66129430
      
      Fixed: Unaligned reads, unspecified evaluation order.
      
      Original change's description:
      > [regexp] Bytecode peephole optimization
      >
      > Bytecodes used by the regular expression interpreter often occur in
      > specific sequences. The number of dispatches in the interpreter can be
      > reduced if those sequences are combined into a single bytecode.
      >
      > This CL adds a peephole optimization pass for regexp bytecodes.
      > This pass checks the generated bytecode for pre-defined sequences that
      > can be merged into a single bytecode.
      >
      > With the currently implemented bytecode sequences a speedup of 1.12x on
      > regex-dna and octane-regexp is achieved.
      >
      > Bug: v8:9330
      > Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63992}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_gcc_rel
      Bug: v8:9330,chromium:1008502,chromium:1008631
      Change-Id: Ib9fc395b6809aa1debdb54d9fba5b7f09a235e5b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828917Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64064}
      282a74c7
  7. 26 Sep, 2019 2 commits
    • Clemens Backes [né Hammacher]'s avatar
      Revert "[regexp] Bytecode peephole optimization" · 05eda1ac
      Clemens Backes [né Hammacher] authored
      This reverts commit 66129430.
      
      Reason for revert: Fails on gcc: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/3394
      
      Original change's description:
      > [regexp] Bytecode peephole optimization
      > 
      > Bytecodes used by the regular expression interpreter often occur in
      > specific sequences. The number of dispatches in the interpreter can be
      > reduced if those sequences are combined into a single bytecode.
      > 
      > This CL adds a peephole optimization pass for regexp bytecodes.
      > This pass checks the generated bytecode for pre-defined sequences that
      > can be merged into a single bytecode.
      > 
      > With the currently implemented bytecode sequences a speedup of 1.12x on
      > regex-dna and octane-regexp is achieved.
      > 
      > Bug: v8:9330
      > Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
      > Commit-Queue: Patrick Thier <pthier@google.com>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63992}
      
      TBR=jgruber@chromium.org,petermarshall@chromium.org,pthier@google.com
      
      Change-Id: Ie526fe3691f6abdd16b51979000fdafb7afce8ef
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826727Reviewed-by: 's avatarClemens Backes [né Hammacher] <clemensb@chromium.org>
      Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63998}
      05eda1ac
    • Patrick Thier's avatar
      [regexp] Bytecode peephole optimization · 66129430
      Patrick Thier authored
      Bytecodes used by the regular expression interpreter often occur in
      specific sequences. The number of dispatches in the interpreter can be
      reduced if those sequences are combined into a single bytecode.
      
      This CL adds a peephole optimization pass for regexp bytecodes.
      This pass checks the generated bytecode for pre-defined sequences that
      can be merged into a single bytecode.
      
      With the currently implemented bytecode sequences a speedup of 1.12x on
      regex-dna and octane-regexp is achieved.
      
      Bug: v8:9330
      Change-Id: I827f93273a5848e5963c7e3329daeb898995d151
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743
      Commit-Queue: Patrick Thier <pthier@google.com>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63992}
      66129430
  8. 29 Aug, 2019 1 commit
  9. 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
  10. 11 Jul, 2019 1 commit
  11. 10 Jul, 2019 1 commit
  12. 02 Apr, 2019 1 commit
  13. 23 Jan, 2019 1 commit
  14. 17 Apr, 2018 1 commit
  15. 13 Oct, 2017 1 commit
  16. 27 Jan, 2016 1 commit
  17. 18 Jan, 2016 2 commits
  18. 17 Nov, 2015 3 commits
  19. 30 Sep, 2015 1 commit
  20. 13 Aug, 2015 1 commit
  21. 11 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove several grab-bag includes from the v8.h header. · 58109a2c
      mstarzinger authored
      This is the first step of turning the v8.h file into a normal header
      instead of an include-the-world header. The new rule is that no other
      header files are allowed to include v8.h, which is enforced by DEPS.
      
      Also the number of includes inside the v8.h file has been drastically
      reduced. Basically the last missing piece is the inclusion of the big
      objects-inl.h file.
      
      This in turn makes many headers follow the IWYU principle.
      
      R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1282503003
      
      Cr-Commit-Position: refs/heads/master@{#30102}
      58109a2c
  22. 26 Jan, 2015 1 commit
  23. 15 Sep, 2014 1 commit
  24. 12 Sep, 2014 2 commits
  25. 04 Jun, 2014 1 commit
  26. 29 Apr, 2014 1 commit
  27. 07 Jun, 2013 1 commit
  28. 06 Jun, 2013 1 commit
  29. 14 Jun, 2012 1 commit
  30. 06 Jun, 2012 1 commit
  31. 22 May, 2012 1 commit
  32. 30 Mar, 2012 1 commit
  33. 08 Sep, 2011 1 commit
  34. 11 May, 2011 1 commit