1. 28 Jun, 2016 1 commit
  2. 09 Jun, 2016 1 commit
    • bmeurer's avatar
      [es6] Fix prototype chain walk for instanceof. · eb1c9e27
      bmeurer authored
      When walking up the prototype chain during OrdinaryHasInstance, we first
      check if the current prototype equals the expected one, and only
      afterwards check the current prototype against null. That's obviously
      wrong if we check something like Proxy, whose prototype is null.
      
      R=yangguo@chromium.org
      BUG=v8:5085
      
      Review-Url: https://codereview.chromium.org/2041103007
      Cr-Commit-Position: refs/heads/master@{#36840}
      eb1c9e27
  3. 29 Mar, 2016 1 commit
    • bmeurer's avatar
      [crankshaft] Address the deoptimization loops of Math.floor, Math.round and Math.ceil. · 978ad03b
      bmeurer authored
      Fix and re-enable the flexible representation for Math.floor (which is used to
      implement Math.ceil) and Math.round, which allows Math.floor and Math.round to
      return double results instead of int32, and therefore allows values outside
      the int32 range, especially -0 is now a valid result, which doesn't deopt.
      
      Also port this feature to x64 and ia32 when the CPU supports the SSE4.1
      extension.
      
      This addresses all the known deoptimization loops related to Math.round
      in the Kraken benchmark suite, and seems to also address most of the
      deoptimization loops related to Math.floor in the Oort Online benchmark.
      
      Drive-by-fix: Import the regression tests for the broken HMathFloorOfDiv
      optimization that caused the initial revert of the feature (for arm64 only
      back then).
      
      BUG=chromium:476477,v8:2890,v8:4059
      R=jarin@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1841513003
      
      Cr-Commit-Position: refs/heads/master@{#35094}
      978ad03b
  4. 29 Jan, 2016 1 commit
    • bmeurer's avatar
      [crankshaft] Fix another deopt loop in slow mode for-in. · 5a7bb33e
      bmeurer authored
      The for-in slow mode implementation in Crankshaft unconditionally
      deoptimizes when %ForInFilter returns undefined instead of just
      skipping the item. Even worse, there's nothing we can learn from
      that deopt, so we will eventually optimize again and hit exactly
      the same problem again once we get back to optimized code.
      
      R=mvstanton@chromium.org
      BUG=v8:3650
      LOG=n
      
      Review URL: https://codereview.chromium.org/1647093002
      
      Cr-Commit-Position: refs/heads/master@{#33609}
      5a7bb33e
  5. 15 Jan, 2016 1 commit
  6. 24 Jun, 2014 1 commit
  7. 04 Jun, 2014 1 commit
  8. 03 Apr, 2014 1 commit
  9. 31 Mar, 2014 1 commit
  10. 28 Feb, 2014 3 commits
  11. 25 Feb, 2014 1 commit
  12. 20 Feb, 2014 1 commit
  13. 14 Feb, 2014 1 commit