1. 10 Jul, 2020 1 commit
  2. 18 Jun, 2020 1 commit
  3. 12 Mar, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Upstream small changes · a2b17a72
      Iain Ireland authored
      This is a grab-bag of small compatibility fixes to make it easier to
      import irregexp into SpiderMonkey. For changes where the commit
      message was longer than the change itself, it didn't seem worth
      opening a separate review.
      
      [regexp] Use uc16 in FilterOneByte
      
      SpiderMonkey uses char16_t instead of uint16_t for its two-byte
      strings. (This matches ICU. It looks like V8 considered making the
      same change, but decided against it: see
      https://bugs.chromium.org/p/v8/issues/detail?id=6487.) Fortunately,
      irregexp is careful about only using uc16, so SpiderMonkey can just
      define uc16 = char16_t and *almost* everything works out. This patch
      fixes the single place in irregexp where that is not true.
      
      [regexp] Remove unreachable return
      
      The return statement at the end of
      RegExpParser::ParseClassCharacterEscape is unreachable, because every
      branch of the switch returns. This triggered static analysis errors in
      SpiderMonkey.
      
      [regexp] Remove trivial assertion
      
      The assertion in BytecodeSequenceNode::ArgumentMapping cannot fail,
      because size_t is an unsigned type. This triggered static analysis
      warnings in SpiderMonkey.
      
      [regexp] Make RegExpStack constructor public
      
      In V8, the RegExpStack's private constructor is called from Isolate,
      which is a friend class. In SpiderMonkey, we use a wrapper around new
      to control where memory is allocated, so we need the RegExpStack
      constructor to be visible outside of Isolate.
      
      [regexp] Refactor Isolate::IncreaseTotalRegexpCodeGenerated
      
      The call-site of Isolate::IncreaseTotalRegexpCodeGenerated is the only
      place inside irregexp where HeapObject::Size is called. SpiderMonkey's
      heap-allocated objects live in arenas, and don't have a standardized
      way of finding the size. In this particular case it would be safe to
      hardcode a size of 0, but leaving HeapObject::Size undefined will
      ensure that SpiderMonkey doesn't silently do the wrong thing if
      somebody in V8 adds a new, more meaningful call to HeapObject::Size.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I5b81e1a261fec8c85a63f71f34cd12d68f638334
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090191
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66676}
      a2b17a72
  4. 08 Oct, 2019 1 commit
  5. 07 Oct, 2019 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