1. 07 Apr, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Add --trace-regexp-graph · 835f53e4
      Jakob Gruber authored
      Until now we've only exposed trace output for the parse- and assembly
      stages of regexp codegen. Debug tracing of the graph was missing. The
      new --trace-regexp-graph flag fills that hole.
      
      Available regexp codegen tracing flags are now:
      
      --trace-regexp-parser
      --trace-regexp-graph
      --trace-regexp-assembler
      
      The output of --trace-regexp-graph can be formatted with `dot`, for
      example:
      
       $ d8 --trace-regexp-graph [...] | dot -Tjpg -o regexp-graph.jpg
      
      Change-Id: Ice593c34f7818c94e42d98e98a31533178bb538b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2808945
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPatrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73825}
      835f53e4
  2. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  3. 11 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [regexp] Don't update last match info in @@split special case · 51fcfd58
      Jakob Gruber authored
      V8 implements a fast-path for RegExp.prototype.split which diverges
      from the spec: instead of creating a new sticky regexp instance
      `splitter` and running it in a loop, we reuse the existing non-sticky
      regexp without looping through each character.
      
      This works fine in most cases, but we run into issues when matching at
      the very end of the string. According to the spec, matches at the end
      of the string are impossible in @@split, but in our fast-path
      implementation they can happen.
      
      The obvious fix would be to remove our fast-path but this comes with
      high performance costs. The fix implemented in this CL adds a special
      flag to `exec` s.t. matches at the end of the string can be treated as
      failures. This is only relevant for @@split.
      
      Bug: chromium:1075514
      Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72644}
      51fcfd58
  4. 09 Feb, 2021 1 commit
  5. 24 Nov, 2020 1 commit
  6. 20 Nov, 2020 1 commit
  7. 16 Nov, 2020 1 commit
  8. 30 Oct, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Add 'l' flag to force experimental engine · 5720d205
      Martin Bidlingmaier authored
      This commit adds the 'l' (linear) RegExp flag (as in e.g. /asdf|123/l)
      that forces execution in linear time.  These regexps are handled by the
      experimental engine.  If the experimental engine cannot handle the
      pattern, an exception is thrown on creation of the regexp.
      
      The commit also adds a new global V8 flag and changes an existing one:
      * --enable-experimental-engine, which turns on recognition of the RegExp
        'l' flag.  Previously this flag also caused all supported regexps to
        be executed by the experimental engine; this is not the case anymore.
      * --default-to-experimental-regexp-engine takes over the previous
        semantics of --enable-experimental-regexp-engine:  We execute all
        supported regexps with the experimental engine.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I5622a89b19404105e8be280d454e9fdd63c003b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461244Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#70892}
      5720d205
  9. 19 Oct, 2020 1 commit
  10. 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
  11. 07 Oct, 2020 1 commit
  12. 23 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Support the msy flags in experimental engine · e6e9cbac
      Martin Bidlingmaier authored
      The m (multiline) and s (dotall) flags just needed to be marked as
      allowed; the required logic was already in the regexp parser.
      
      A regexp /<x>/ without the y (sticky) flag is equivalent to the sticky
      regexp /.*?<x>/y.  The interpreter now assumes that every regexp is
      sticky, and the compiler appends a preamble corresponding to /.*?/
      before non-sticky regexps.  To reuse existing code for compiling this
      preamble, the logic for each kind of quantifier is now in a separate
      function and called from VisitQuantifier and for the preamble.
      
      The commit also includes some improvements/fixes for character ranges:
      - Empty character ranges/disjunctions should never match, but before
        this commit they would *always* match.
      - The check of the range bounds in CanBeHandledVisitor was unncessary;
        without the unicode flag this can't be a range that can't be specified
        in 2-byte codepoints, and once we support unicode we simply support
        all codepoints.
      - The capacity of the list containing the complementary intervals of a
        character range is now calculated more accurately.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I71a0e07279b4e1140c0ed1651b3714200c801de9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404766
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70082}
      e6e9cbac
  13. 16 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Support capture groups in experimental engine · 98b8ca89
      Martin Bidlingmaier authored
      This commit adds support for capture groups (as in e.g. /x(123|abc)y/)
      in the experimental regexp engine.  Now every InterpreterThread owns a
      register array containing (sub)match boundaries. There is a new
      instruction to record the current input index in some register.
      
      Submatches in quantifier bodies should be reported only if they occur
      during the last repetition.  Thus we reset those registers before
      attempting to match the body of a quantifier.  This is implemented with
      another new instruction.
      
      Because of concerns for the growing sizeof the NfaInterpreter object
      (which is allocated on the stack), this commit replaces the
      `SmallVector` members of the NfaInterpreter with zone-allocated arrays.
      Register arrays, which for a fixed regexp are all the same size, are
      allocated with a RecyclingZoneAllocator for cheap memory reclamation via
      a linked list of equally-sized free blocks.
      
      Possible optimizations for management of register array memory:
      1. If there are few register per thread, then it is likely faster to
         store them inline in the InterpreterThread struct.
      2. re2 implements copy-on-write:  InterpreterThreads can share the same
         register array. If a thread attempts to write to shared register
         array, the register array is cloned first.
      3. The register at index 1 contains the end of the match; this is only
         written to right before an ACCEPT statement.  We could make ACCEPT
         equivalent to what's currently CAPTURE 1 followed by ACCEPT.  We
         could then save the memory for register 1 for threads that haven't
         finished yet.  This is particularly interesting if now optimization 1
         kicks in.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I2c0503206ce331e13ac9912945bb66736d740197
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2390770
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69929}
      98b8ca89
  14. 08 Sep, 2020 1 commit
    • Martin Bidlingmaier's avatar
      [regexp] Check capture_count before using experimental engine · bc4174cc
      Martin Bidlingmaier authored
      Sometimes the parser throws away redundant parts of the AST while
      parsing.  For example, the regexp /(?:(?=(f)o))?f/ is (almost)
      equivalent to just /f/ because the optional block (...)? is zero-length.
      The parser notices this and returns the same tree as for /f/.  However,
      there is a capture inside the (...)? block (which is never recorded
      because the quantifier containing it can only match zero-width, which is
      considered failure), so in this case it doesn't suffice to check that
      the regexp AST doesn't contain captures.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:10765
      Change-Id: I6145849d95b3522a397eadd2bae63d1d8e880f28
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2397896Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Martin Bidlingmaier <mbid@google.com>
      Cr-Commit-Position: refs/heads/master@{#69733}
      bc4174cc
  15. 31 Aug, 2020 1 commit
  16. 18 Aug, 2020 1 commit
  17. 28 Apr, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Handlify RegExpCompileData::code · 6bb3f0c0
      Iain Ireland authored
      RegExpMacroAssembler::GetCode returns a Handle<Object>. However, that
      Handle is almost immediately dereferenced, and is stored as a bare
      Object in both RegExpCompiler::CompilationResult and RegExpCompileData.
      
      This makes SpiderMonkey's rooting hazard analysis somewhat
      antsy. While RegExpCompileData is alive on the stack, the hazard
      analysis will not allow any calls that might GC, because it isn't
      smart enough to prove that the code field can't be clobbered by a GC.
      
      As far as I can tell, there is no real hazard here, but storing a
      Handle in RegExpCompileData instead of a bare Object will simplify SM
      and prevent a future patch from accidentally breaking something.
      
      Bug: v8:10406
      Change-Id: I9642dd05c591bfd23b340a89df2f2bf5c9fcac2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2161578Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67441}
      6bb3f0c0
  18. 21 Apr, 2020 3 commits
  19. 19 Mar, 2020 3 commits
    • Iain Ireland's avatar
      Reland "[regexp] Rewrite error handling" · 560f2d8b
      Iain Ireland authored
      This is a reland of e80ca24c
      
      Original change's description:
      > [regexp] Rewrite error handling
      >
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      >
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      >
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      >
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      >
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      >
      > R=jgruber@chromium.org
      >
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66798}
      560f2d8b
    • Leszek Swirski's avatar
      Revert "[regexp] Rewrite error handling" · 2193f691
      Leszek Swirski authored
      This reverts commit e80ca24c.
      
      Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)
      
      Original change's description:
      > [regexp] Rewrite error handling
      > 
      > This patch modifies irregexp's error handling. Instead of representing
      > errors as C strings, they are represented as an enumeration value
      > (RegExpError), and only converted to strings when throwing the error
      > object in regexp.cc. This makes it significantly easier to integrate
      > into SpiderMonkey. A few notes:
      > 
      > 1. Depending on whether the stack overflows during parsing or
      >    analysis, the stack overflow message can vary ("Stack overflow" or
      >    "Maximum call stack size exceeded"). I kept that behaviour in this
      >    patch, under the assumption that stack overflow messages are
      >    (sadly) the sorts of things that real world code ends up depending
      >    on.
      > 
      > 2. Depending on the point in code where the error was identified,
      >    invalid unicode escapes could be reported as "Invalid Unicode
      >    escape", "Invalid unicode escape", or "Invalid Unicode escape
      >    sequence". I fervently hope that nobody depends on the specific
      >    wording of a syntax error, so I standardized on the first one. (It
      >    was both the most common, and the most consistent with other
      >    "Invalid X escape" messages.)
      > 
      > 3. In addition to changing the representation, this patch also adds an
      >    error_pos field to RegExpParser and RegExpCompileData, which stores
      >    the position at which an error occurred. This is used by
      >    SpiderMonkey to provide more helpful messages about where a syntax
      >    error occurred in large regular expressions.
      > 
      > 4. This model is closer to V8's existing MessageTemplate
      >    infrastructure. I considered trying to integrate it more closely
      >    with MessageTemplate, but since one of our stated goals for this
      >    project was to make it easier to use irregexp outside of V8, I
      >    decided to hold off.
      > 
      > R=​jgruber@chromium.org
      > 
      > Bug: v8:10303
      > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66784}
      
      TBR=jgruber@chromium.org,iireland@mozilla.com
      
      Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10303
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66786}
      2193f691
    • Iain Ireland's avatar
      [regexp] Rewrite error handling · e80ca24c
      Iain Ireland authored
      This patch modifies irregexp's error handling. Instead of representing
      errors as C strings, they are represented as an enumeration value
      (RegExpError), and only converted to strings when throwing the error
      object in regexp.cc. This makes it significantly easier to integrate
      into SpiderMonkey. A few notes:
      
      1. Depending on whether the stack overflows during parsing or
         analysis, the stack overflow message can vary ("Stack overflow" or
         "Maximum call stack size exceeded"). I kept that behaviour in this
         patch, under the assumption that stack overflow messages are
         (sadly) the sorts of things that real world code ends up depending
         on.
      
      2. Depending on the point in code where the error was identified,
         invalid unicode escapes could be reported as "Invalid Unicode
         escape", "Invalid unicode escape", or "Invalid Unicode escape
         sequence". I fervently hope that nobody depends on the specific
         wording of a syntax error, so I standardized on the first one. (It
         was both the most common, and the most consistent with other
         "Invalid X escape" messages.)
      
      3. In addition to changing the representation, this patch also adds an
         error_pos field to RegExpParser and RegExpCompileData, which stores
         the position at which an error occurred. This is used by
         SpiderMonkey to provide more helpful messages about where a syntax
         error occurred in large regular expressions.
      
      4. This model is closer to V8's existing MessageTemplate
         infrastructure. I considered trying to integrate it more closely
         with MessageTemplate, but since one of our stated goals for this
         project was to make it easier to use irregexp outside of V8, I
         decided to hold off.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66784}
      e80ca24c
  20. 16 Mar, 2020 1 commit
  21. 21 Feb, 2020 1 commit
  22. 23 Jan, 2020 1 commit
  23. 21 Nov, 2019 1 commit
  24. 20 Nov, 2019 1 commit
  25. 19 Nov, 2019 1 commit
  26. 15 Nov, 2019 1 commit
  27. 21 Oct, 2019 2 commits
    • Jakob Gruber's avatar
      [regexp] Apply the backtrack limit in jitted code · 0089006f
      Jakob Gruber authored
      .. similar to how it is applied in the interpreter. We reserve a stack
      slot for the backtrack count, increment it on each backtrack, and fail
      if the limit is hit.
      
      Bug: v8:9695
      Change-Id: I835888c612d6c8bfa2f34e73ab8c8241dcabc6ed
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864938Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64426}
      0089006f
    • Jakob Gruber's avatar
      [regexp] Add a backtracking limit in the interpreter · 48756fcf
      Jakob Gruber authored
      V8 uses a backtracking regexp engine, which has the caveat that some
      regexp patterns can have exponential runtime behavior when excessive
      backtracking is involved.
      
      Especially when regexp patterns are user-controlled, it would be useful
      to be able to set an upper limit for a single regexp execution. This CL
      takes an initial step in that direction by adding a backtracking limit
      (intended to approximate execution time):
      
      - The limit is stored in the JSRegExp's data array.
      - A limit can currently only be set through the %NewRegExpWithLimit
      runtime function.
      - The limit is applied during interpreter execution. When exceeded, the
      interpreter stops execution and returns FAILURE (even if continued
      execution would at some later point have resulted in SUCCESS).
      
      In follow-up CLs, this mechanism will be extended to work in jitted
      regexp code, and exposed through the V8 API.
      
      Bug: v8:9695
      Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64417}
      48756fcf
  28. 01 Oct, 2019 2 commits
    • 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
    • Ana Peško's avatar
      Reland "[regexp] Eagerly tier-up for very long strings" · 14ffd21d
      Ana Peško authored
      This is a reland of cfb60d43
      
      Original change's description:
      > [regexp] Eagerly tier-up for very long strings
      > 
      > For very long subject strings, the regexp interpreter is currently much slower
      > than the native machine code execution. This CL implements eager tier-up to the
      > compiler to avoid the performance penalty for subject strings of length greater
      > than 1000.
      > 
      > Change-Id: I244ccbd60255e0f3bedc493b1cc3d25cdd42133e
      > Bug: v8:9566
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1829273
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Ana Pesko <anapesko@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64046}
      
      Bug: v8:9566
      Change-Id: I81a10728c64ce3b35258c31eb8178e458d3de205
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1832167Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ana Pesko <anapesko@google.com>
      Cr-Commit-Position: refs/heads/master@{#64063}
      14ffd21d
  29. 30 Sep, 2019 2 commits
  30. 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