1. 24 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [utils] Add CompareCharsEqual · 52cfffde
      Leszek Swirski authored
      Add a CompareCharsEqual to complement CompareChars, where we only care
      about equality and not ordering. For such cases, we can memcmp for two-
      byte as well as one-byte strings (we can't for CompareChars because the
      ordering would be incorrect on little-endian systems).
      
      Replace uses of CompareChars that only compare the result against zero,
      with CompareCharsEqual. Additionally, use some template magic to
      simplify the "make unsigned" operation in these methods.
      
      Change-Id: I0d65bee81b98d3938d15daa4af331c90558ea84f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557980
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71385}
      52cfffde
  2. 20 Nov, 2020 1 commit
  3. 09 Nov, 2020 1 commit
  4. 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
  5. 18 Aug, 2020 1 commit
  6. 03 Jun, 2020 1 commit
  7. 20 May, 2020 1 commit
  8. 19 May, 2020 2 commits
  9. 21 Apr, 2020 1 commit
    • Jakob Gruber's avatar
      [regexp] Consistent expectations for output registers · fe609139
      Jakob Gruber authored
      ... between the interpreter and generated code.
      
      Prior to this CL, pre- and post conditions on the output register
      array differed between the interpreter and generated code.
      
      Interpreter
      Pre: `output` fits captures and temporary registers.
      Post: None.
      
      Generated code
      Pre:  `output` fits capture registers.
      Post: `output` is modified if and only if the match succeeded.
      
      This CL changes the interpreter to match generated code pre- and
      post conditions by allocating space for temporary registers inside
      the interpreter.
      
      Drive-by: Add MaxRegisterCount, RegistersForCaptureCount helpers.
      
      Bug: chromium:1067270
      Change-Id: I2900ef2f31207d817ec7ead3e0e2215b23b398f0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135642
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67268}
      fe609139
  10. 06 Apr, 2020 1 commit
  11. 17 Mar, 2020 1 commit
    • Iain Ireland's avatar
      [regexp] Refactor to simplify embedding irregexp · 40d1b660
      Iain Ireland authored
      Some code at the interface between irregexp and the rest of V8 uses
      V8-specific APIs that are not used elsewhere in irregexp. For example,
      only a handful of functions in irregexp call or are called from
      generated code. When embedding irregexp into SpiderMonkey, these
      functions are an obstacle, because they are dead code, but still have
      to compile.
      
      To simplify the process of embedding, this patch does two things:
      
      1. It moves StringCharacterPosition out of irregexp and into
      objects/string, renaming it "AddressOfCharacterAt".
      
      2. It guards the following set of functions with
      '#ifndef COMPILING_IRREGEXP_FOR_EXTERNAL_EMBEDDER':
      - IrregexpInterpreter::MatchForCallFromJs
      - NativeRegExpMacroAssembler::CheckStackGuardState
      - NativeRegExpMacroAssembler::Match
      - NativeRegExpMacroAssembler::Execute
      
      This will have no effect in a V8 build, but can be defined by
      SpiderMonkey or another embedder to omit the problematic functions.
      
      In the future, if we attempt to make a cleaner separation between V8
      and irregexp, these functions will be a good place to start defining
      the API boundary.
      
      R=jgruber@chromium.org
      
      Bug: v8:10303
      Change-Id: I9f531a36e4f13440cafb0d0ade921f4c09f39c05
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097220Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66750}
      40d1b660
  12. 02 Mar, 2020 1 commit
  13. 16 Jan, 2020 1 commit
  14. 22 Oct, 2019 1 commit
  15. 21 Oct, 2019 1 commit
    • 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
  16. 10 Oct, 2019 1 commit
  17. 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
  18. 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
  19. 24 Sep, 2019 1 commit
  20. 12 Sep, 2019 1 commit
    • Patrick Thier's avatar
      [regexp] Secure interpreter dispatch. · 67a70d7e
      Patrick Thier authored
      Currently the dispatch table could be accessed out of bounds if something
      is wrong with the generated bytecode.
      OOB access of the dispatch table can lead to jumps to arbitrary addresses
      in the code space.
      
      This CL prevents this issue by changing the following:
      BYTECODE_MASK now filters out all bits not currently used for bytecodes.
      All unused slots between the last actually defined bytecode and
      BYTECODE_MASK are now filled with BREAK Bytecodes (invalid operation).
      This way we can not access out of bounds of the dispatch table if
      something is broken/tampered with, preventing jumps to arbitrary code.
      
      Bug: v8:9699
      Change-Id: Ibce591ae94b52472ba74a9fd0666e55185af7b2c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795349
      Commit-Queue: Patrick Thier <pthier@google.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63708}
      67a70d7e
  21. 09 Sep, 2019 1 commit
  22. 29 Aug, 2019 3 commits
    • Patrick Thier's avatar
      [regexp] Consolidate calls to jitted irregexp and regexp interpreter · 213504b9
      Patrick Thier authored
      The code fields in a JSRegExp object now either contain irregexp
      compiled code or a trampoline to the interpreter. This way the code
      can be executed without explicitly checking if the regexp shall be
      interpreted or executed natively.
      In case of interpreted regexp the generated bytecode is now stored in
      its own fields instead of the code fields for Latin1 and UC16
      respectively.
      The signatures of the jitted irregexp match and the regexp interpreter
      have been equalized.
      
      Bug: v8:9516
      Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513
      Commit-Queue: Patrick Thier <pthier@google.com>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63457}
      213504b9
    • Jakob Gruber's avatar
      [regexp] Add an offset argument CheckAtStart · 2e0bc516
      Jakob Gruber authored
      Similar to CheckNotAtStart, one can now apply an offset to the
      CheckAtStart operation. Due to a recent change, all callsites of
      CheckNotAtStart now need to pass an offset, whereas previously the
      offset was just assumed to be zero.
      
      Bug: chromium:996391
      Change-Id: Ia59a584e93e5384479f05abddef7859b420b023a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773272
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63444}
      2e0bc516
    • Jakob Gruber's avatar
      [regexp] Add dedicated flags for printing regexp code and bytecode · eebb18d3
      Jakob Gruber authored
      Printing regexp code used to behind the generic --print-code flag, but
      there was no way to distinguish between irregexp-generated code; and
      printing regexp bytecode was not supported at all (the
      --trace-regexp-bytecodes flag *did* exist, but prints the execution
      trace at runtime and not the generated bytecode sequence).
      
      This CL adds two new flags:
      
      --print-regexp-code
      --print-regexp-bytecode
      
      Regexp code is no longer printed as part of --print-code.
      
      Example output for --print-regexp-bytecode:
      
      generated bytecode for regexp pattern: .(?<!^.)
      0x1ddcc614cbd0     0  PUSH_BT, 02, 00, 00, 00, c0, 00, 00, 00 .......
      0x1ddcc614cbd8     8  LOAD_CURRENT_CHAR, 11, 00, 00, 00, b0, 00, 00, 00 .......
      0x1ddcc614cbe0    10  CHECK_CHAR, 18, 0a, 00, 00, b0, 00, 00, 00 .......
      0x1ddcc614cbe8    18  CHECK_CHAR, 18, 0d, 00, 00, b0, 00, 00, 00 .......
      0x1ddcc614cbf0    20  PUSH_CP, 01, 00, 00, 00 ...
      
      Bug: chromium:996391
      Change-Id: I731defbd7cf9ed29753a39bb1d7205dc136ca950
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773249
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63442}
      eebb18d3
  23. 13 Aug, 2019 1 commit
  24. 12 Aug, 2019 1 commit
  25. 08 Aug, 2019 1 commit
  26. 26 Jul, 2019 1 commit
  27. 24 Jul, 2019 1 commit
  28. 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
  29. 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
  30. 17 Jul, 2019 2 commits
  31. 18 Jun, 2019 1 commit
  32. 12 Jun, 2019 1 commit
  33. 06 Jun, 2019 1 commit
  34. 05 Jun, 2019 1 commit
  35. 29 May, 2019 1 commit