1. 20 Aug, 2019 1 commit
  2. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "[regexp] Better quick checks on loop entry nodes" · bea0ffd0
      Seth Brenith authored
      This is a reland of 4b15b984
      
      Updates since original: fix an arithmetic overflow bug, remove an invalid
      DCHECK, add a unit test that would trigger that DCHECK.
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      >
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      >
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      >
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      >
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      >
      > Bug: v8:9305
      >
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      Bug: v8:9305
      Change-Id: I992070d383009013881bf778242254c27134b650
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63009}
      bea0ffd0
  3. 30 Jul, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "[regexp] Better quick checks on loop entry nodes" · 51afbd1a
      Leszek Swirski authored
      This reverts commit 4b15b984.
      
      Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      > 
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      > 
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      > 
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      > 
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      > 
      > Bug: v8:9305
      > 
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      TBR=jgruber@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9305
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62977}
      51afbd1a
  4. 29 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [regexp] Better quick checks on loop entry nodes · 4b15b984
      Seth Brenith authored
      Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      change is inspired by attempting to exit earlier from generated RegExp
      code, when no further matches are possible because any match would be
      too long. The motivating example this time is the following expression,
      which tests whether a string of Unicode playing cards has five of the
      same suit in a row:
      
      /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      
      A human reading this expression can readily see that any match requires
      at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      each repeated option reports its minimum distance to the end of a match
      as zero. This is correct, because the LoopChoiceNode's behavior depends
      on additional state (the loop counter). However, the preceding node, a
      SET_REGISTER action that initializes the loop counter, could confidently
      state that it consumes at least 10 characters. Furthermore, when we try
      to emit a quick check for that action, we could follow only paths from
      the LoopChoiceNode that are possible based on the minimum iteration
      count. This change implements both of those "could"s.
      
      I expect this improvement to apply pretty broadly to expressions that
      use minimum repetition counts and that don't meet the criteria for
      unrolling. In this particular case, I get about 12% improvement on the
      overall UniPoker test, due to reducing the execution time of this
      expression by 85% and the execution time of another similar expression
      that checks for n-of-a-kind by 20%.
      
      Bug: v8:9305
      
      Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62963}
      4b15b984
  5. 08 Jun, 2019 1 commit
    • Benedikt Meurer's avatar
      [interpreter] Do ToObject implicitly as part of CloneObject. · 92c6af8a
      Benedikt Meurer authored
      The CloneObject bytecode was only able to handle objects, null and
      undefined, and explicit bytecode had to be generated to perform the
      ToObject outside the bytecode (unlike the other IC bytecodes that
      just perform the ToObject implicitly). That means the simplest possible
      object cloning would also generate a sequence of 5 bytecodes (at least):
      
      ```
         Mov <register>, a0
         JumpIfNull @1
         JumpIfUndefined @1
         ToObject <register>
      1: CloneObject <register>
      ```
      
      That is quite wasteful and unnecessary, since the core logic in the
      runtime already does the ToObject properly anyways. This change
      refactors the CloneObjectIC slightly to behave more like the other ICs
      and do the ToObject implicitly when necessary.
      
      Bug: v8:7611, v8:9114, v8:9183, v8:9343
      Change-Id: I11973e90bf875f154a5a7739287bee17041e4a7a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649554Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62064}
      92c6af8a
  6. 03 May, 2019 1 commit
  7. 29 Apr, 2019 1 commit
    • Benedikt Meurer's avatar
      [runtime] Optimize general object spread. · 4995c85f
      Benedikt Meurer authored
      This adds a new %_CopyDataProperties intrinsic, that reuses most of the
      existing machinery that we already have in place for Object.assign() and
      computed property names in object literals. This speeds up the general
      case for object spread (where the spread is not the first item in an
      object literal) and brings it on par with Object.assign() at least - in
      most cases it's significantly faster than Object.assign().
      
      In the test case [1] referenced from the bug, the performance goes from
      
        objectSpreadLast: 3624 ms.
        objectAssignLast: 1938 ms.
      
      to
      
        objectSpreadLast: 646 ms.
        objectAssignLast: 1944 ms.
      
      which corresponds to a **5-6x performance boost**, making object spread
      faster than Object.assign() in general.
      
      Drive-by-fix: This refactors the Object.assign() fast-path in a way that
      it can be reused appropriately for object spread, and adds another new
      builtin SetDataProperties, which does the core of the Object.assign()
      work. We can teach TurboFan to inline Object.assign() based on the new
      SetDataProperties builtin at some later point to further optimize
      Object.assign().
      
      [1]: https://gist.github.com/bmeurer/0dae4a6b0e23f43d5a22d7c91476b6c0
      
      Bug: v8:9167
      Change-Id: I57bea7a8781c4a1e8ff3d394873c3cd4c5d73834
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587376Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61100}
      4995c85f
  8. 27 Nov, 2018 1 commit
  9. 08 Nov, 2018 1 commit
  10. 07 Nov, 2018 1 commit
    • Caitlin Potter's avatar
      [CloneObjectIC] clone MutableHeapNumbers instead of referencing them · bf84766a
      Caitlin Potter authored
      Adds a helper macro "CloneIfMutablePrimitive", which tests if the
      operand is a MutableHeapNumber, and if so, clones it, otherwise
      returning the original value.
      
      Also modifies the signature of "CopyPropertyArrayValues" to take a
      "DestroySource" enum, indicating whether or not the resulting object is
      supplanting the source object or not, and removes all default
      parameters from that macro (which were not used anyways).
      
      This corrects the issue reported in chromium:901301, where
      StaNamedOwnProperty was replacing the value of a MutableHeapNumber
      referenced by both the cloned object and the source object.
      
      BUG=chromium:901301, v8:7611
      R=cbruni@chromium.org, jkummerow@chromium.org
      
      Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
      Reviewed-on: https://chromium-review.googlesource.com/c/1318096
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57304}
      bf84766a
  11. 11 Sep, 2018 1 commit
    • Caitlin Potter's avatar
      [CloneObjectIC] add CSA implementation of slow case · fbcf0221
      Caitlin Potter authored
      The CSA implementation is a separate handler so that TF has the
      opportunity to reduce to a direct call, skipping some of the dispatching
      in the CloneObjectIC stub.
      
      This patch moves the looping over a source object's keys and values into the
      base CodeStubAssembler, so that it can be shared between ObjectAssignFast
      and CloneObjectIC_Slow.
      
      During each step of the loop, storing is delegated to a new SetPropertyInLiteral
      helper in KeyedStoreGenericGenerator, which performs a store without consulting
      the prototype chain, and automatically reconfigures accessors into data
      properties regardless of their attributes.
      
      BUG=v8:8067, v8:7611
      R=ishell@chromium.org, jkummerow@chromium.org
      
      Change-Id: I06ae89f37e9b4265aab67389cf68a96529f90578
      Reviewed-on: https://chromium-review.googlesource.com/1182122
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55806}
      fbcf0221
  12. 04 Aug, 2018 1 commit
  13. 01 Aug, 2018 1 commit
  14. 31 Jul, 2018 2 commits
  15. 27 Jul, 2018 2 commits
  16. 25 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] fix ClusterFuzz regressions (and remaining nits) in CloneObject · d6efcbf0
      Caitlin Potter authored
      Includes fixes for several ClusterFuzz regressions:
      
      1) fix an invalid Handle-cast in ic.cc (chromium:866282)
      
      2) fix for improper accounting of used/unused inobject
      fields, found by clusterfuzz (chromium:866357).
      
      3) fix number of control outputs for the JSCloneObject
      operator to be used by IfSuccess and IfException nodes (chromium:866727).
      
      4) fix property constness in out-of-object properties of fast-cloned
      object to be compatible with DCHECKs in StoreIC (chromium:866861).
      
      Also includes the fixups missing from the initial commit, and
      regression tests
      
      BUG=v8:7611, chromium:866282, chromium:866357, chromium:866727, chromium:866861
      R=jkummerow@chromium.org, mvstanton@chromium.org
      TBR=rmcilroy@chromium.org
      
      Change-Id: I77220308482f16db2893c0dcebec36530d0f5540
      Reviewed-on: https://chromium-review.googlesource.com/1146297
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54706}
      d6efcbf0
  17. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
  18. 20 Feb, 2018 1 commit
  19. 28 Nov, 2017 1 commit
  20. 17 Nov, 2017 1 commit
  21. 25 Oct, 2017 1 commit