1. 11 Nov, 2019 1 commit
  2. 05 Nov, 2019 1 commit
  3. 30 Oct, 2019 1 commit
  4. 22 Oct, 2019 1 commit
    • Igor Sheludko's avatar
      [builtins] Port String.prototype.substr to Torque · 3c57ad21
      Igor Sheludko authored
      ... and refactor String.prototype.substring.
      
      This is done to simplify cleaning up callers of ConvertToRelativeIndex()
      in a follow-up CL.
      
      This CL also introduces Smi-overflow friendly helper function
        ClampToIndexRange(index: JSAny, min: uintptr, max: uintptr): uintptr
      
      which can be used in other String builtins as a better alternative to
        NumberMin(NumberMax(value, min), max)
      pattern.
      
      Bug: v8:8996, v8:4153
      Change-Id: Ie1bb5ab305ebf851c033d109ffe9e6afb9418274
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872392
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64463}
      3c57ad21
  5. 25 Sep, 2019 1 commit
  6. 23 Sep, 2019 1 commit
  7. 13 Sep, 2019 1 commit
  8. 04 Sep, 2019 1 commit
  9. 27 Aug, 2019 1 commit
  10. 23 Aug, 2019 1 commit
  11. 20 Aug, 2019 1 commit
  12. 19 Aug, 2019 1 commit
  13. 29 Jul, 2019 1 commit
    • Jakob Gruber's avatar
      [regexp] Restructure fast path check logic · c6b1ef0e
      Jakob Gruber authored
      Prior to this CL, the regexp fast path check is stricter than it
      needs to be. For example, adding any arbitrary property on the regexp
      prototype would move the execution of all regexp builtins in the same
      context onto the slow path. This actually happens in the real world:
      popular web frameworks commonly monkey-patch builtin prototypes to add
      functionality.
      
      The intent of this CL is to widen the fast path for regexp builtins s.t.
      modifications of the prototype that do not conflict with our
      requirements stay on the fast path.
      
      This is done by extending the current fast path check with an
      additional step. If checking the prototype map identity or
      relevant prototype property constness fails, we now compare the actual
      value of all relevant properties against the expected value. If these
      match, the prototype can be considered fast.
      
      The new step as described in the previous paragraph is part of the
      permissive fast path check (BranchIfFastRegExp_Permissive). The strict
      variant (BranchIfFastRegExp_Strict) is also still required by a few
      spots. We should refactor these to also allow the permissive check in
      follow-up work.
      
      Bug: v8:5577,chromium:977382
      Change-Id: I69b2244e68ccfbd00edf17fc326aa4b5f5d089fa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706056
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62948}
      c6b1ef0e
  14. 01 Jul, 2019 1 commit
  15. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  16. 21 May, 2019 2 commits
  17. 14 May, 2019 1 commit
  18. 09 May, 2019 1 commit
  19. 06 May, 2019 1 commit
  20. 04 Apr, 2019 1 commit
  21. 14 Mar, 2019 1 commit
  22. 14 Nov, 2018 1 commit
  23. 18 Oct, 2018 1 commit
  24. 08 Oct, 2018 1 commit
    • Hai Dang's avatar
      Reland "Add fast path for spreading primitive strings." · 760eed05
      Hai Dang authored
      This is a reland of ef2a19a2.
      Use AllocateJSArray to avoid allocating an empty fixed array.
      
      Original change's description:
      > Add fast path for spreading primitive strings.
      >
      > This improves the performance on primitive strings of
      > IterableToListWithSymbolLookup, which implements the
      > CreateArrayFromIterable bytecode. The fast path is only
      > taken if the string iterator protector is valid (that is,
      > String.prototype[Symbol.iterator] and
      > String.prototype[Symbol.iterator]().next are untouched).
      >
      > This brings spreading of primitive strings closer to the
      > performance of the string iterator optimizations.
      > (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
      >
      > Bug: chromium:881273, v8:7980
      > Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
      > Reviewed-on: https://chromium-review.googlesource.com/1243110
      > Commit-Queue: Hai Dang <dhai@google.com>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56329}
      
      Bug: chromium:881273, v8:7980
      Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3
      Reviewed-on: https://chromium-review.googlesource.com/c/1267497
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56438}
      760eed05
  25. 04 Oct, 2018 1 commit
  26. 02 Oct, 2018 1 commit
  27. 13 Sep, 2018 1 commit
  28. 07 Sep, 2018 1 commit
  29. 18 Jun, 2018 1 commit
  30. 18 May, 2018 1 commit
  31. 17 May, 2018 1 commit
  32. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored
      Stubs and builtins are very similar. The main differences are that
      stubs can be parameterized and may be generated at runtime, whereas
      builtins are generated at mksnapshot-time and shipped with the snapshot
      (or embedded into the binary).
      
      My main motivation for these conversions is that we can generate
      faster calls and jumps to (embedded) builtins callees from (embedded)
      builtin callers. Instead of going through the builtins constants table
      indirection, we can simply do a pc-relative call/jump.
      
      This also unlocks other refactorings, e.g. removal of
      CallRuntimeDelayed.
      
      TBR=mlippautz@chromium.org
      
      Bug: v8:6666
      Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
      Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  33. 05 Apr, 2018 1 commit
  34. 12 Jan, 2018 2 commits
  35. 15 Nov, 2017 1 commit
  36. 08 Nov, 2017 1 commit
    • jgruber's avatar
      [string] Fix regexp fast path in MaybeCallFunctionAtSymbol · 55a98076
      jgruber authored
      The regexp fast path in MaybeCallFunctionAtSymbol had an issue in which
      we'd call ToString after checking that the given {object} was a fast
      regexp and deciding to take the fast path. This is invalid since
      ToString() can call into user-controlled JS and may mutate {object}.
      
      There's no way to place the ToString call correctly in this instance:
      1 before BranchIfFastRegExp, it's a spec violation if we end up on the
        slow regexp path;
      2 the problem with the current location is already described above;
      3 and we can't place it into the fast-path regexp builtin (e.g.
        RegExpReplace) either due to the same reasons as 1.
      
      The solution in this CL is to restrict the fast path to string
      arguments only, i.e. cases where ToString would be a nop and can safely
      be skipped.
      
      Bug: chromium:782145
      Change-Id: Ifd35b3a9a6cf2e77c96cb860a8ec98eaec35aa85
      Reviewed-on: https://chromium-review.googlesource.com/758257
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49213}
      55a98076
  37. 02 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [builtins] Support two byte strings in StringEqual builtin. · f597eec1
      Benedikt Meurer authored
      This CL adds support for two byte string comparisons to the StringEqual
      builtin, which so far was bailing out to the generic %StringEqual
      runtime function whenever any two-byte string was involved. This made
      comparisons that involved two-byte strings, either comparing them to
      one-byte strings or comparing two two-byte strings, up to 3x slower than
      if only one-byte strings were involved.
      
      With this change, all direct string (SeqString or ExternalString)
      equality checks are roughly on par now, and the weird performance cliff
      is gone. On the micro-benchmark from the bug we go from
      
        stringEqualBothOneByteSeqString: 162 ms.
        stringEqualTwoByteAndOneByteSeqString: 446 ms.
        stringEqualOneByteAndTwoByteSeqString: 438 ms.
        stringEqualBothTwoByteSeqString: 472 ms.
      
      to
      
        stringEqualBothOneByteSeqString: 151 ms.
        stringEqualTwoByteAndOneByteSeqString: 158 ms.
        stringEqualOneByteAndTwoByteSeqString: 166 ms.
        stringEqualBothTwoByteSeqString: 160 ms.
      
      which is the desired result. On the esprima test of the
      web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
      the savings of going to the runtime for many StringEqual comparisons.
      
      Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
      with proper typing to avoid the unnecessary shifts on 64-bit platforms
      when keeping the length tagged initially in StringEqual.
      
      Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
      Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
      Reviewed-on: https://chromium-review.googlesource.com/749223Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49067}
      f597eec1
  38. 25 Oct, 2017 1 commit