1. 04 Mar, 2019 1 commit
  2. 24 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove inlining support for the deprecated pipeline. · 76fd6f25
      bmeurer authored
      The deprecated pipeline is used for asm.js only, where we forcibly
      disable inlining anyways (for performance reasons), so inlining via
      the AstGraphBuilder is essentially dead code by now, thus there's no
      point in trying to keep that around in the code base.
      
      Also nuke the test-run-inlining.cc file, which would require some heavy
      surgery (for probably little benefit), and move the useful tests for
      mjsunit tests instead.
      
      BUG=v8:2206,v8:5657
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2527053002
      Cr-Commit-Position: refs/heads/master@{#41245}
      76fd6f25
  3. 26 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Fix overly aggressive dead code elimination. · 32346aae
      bmeurer authored
      When we eliminate nodes during truncation analysis that have no value
      uses, we must make sure that we do not eliminate speculative number
      operations that would have side effects depending on the inputs, i.e.
      for example a SpeculativeNumberMultiply(x,y) does ToNumber(x) and
      ToNumber(y) first, so if either x or y could throw an exception during
      ToNumber conversion, we must not eliminate the multiplication, even if
      it has no value uses (some later pass may kill the actual machine
      multiplication, but the checks on the inputs have to remain still).
      So we check whether both x and y are PlainPrimitive, i.e. neither
      Receiver nor Symbol, which could raise exceptions for ToNumber, and
      only in that case we propagate the "unusedness" of the node to its
      inputs.
      
      This also uncovered a bug with the type of Dead, which must be None,
      as this represents an impossible value, so we had to fix that too.
      
      Also the dead code removal will not work correctly for constants (i.e.
      pure nodes with no value inputs), as those might be cached and hence
      we might resurrect them for an unrelated node lowering during
      SimplifiedLowering and only later kill the actual node (replacing its
      uses with Dead), which would then also replace the new use with Dead.
      So that was fixed as well. This shouldn't change anything for the
      result, as unused constants automagically disappear from the graph later
      on anyways.
      
      R=yangguo@chromium.org
      BUG=chromium:631318
      
      Review-Url: https://codereview.chromium.org/2182003002
      Cr-Commit-Position: refs/heads/master@{#38038}
      32346aae
  4. 28 Jun, 2016 1 commit
  5. 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
  6. 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
  7. 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
  8. 15 Jan, 2016 1 commit
  9. 24 Jun, 2014 1 commit
  10. 04 Jun, 2014 1 commit
  11. 03 Apr, 2014 1 commit
  12. 31 Mar, 2014 1 commit
  13. 28 Feb, 2014 3 commits
  14. 25 Feb, 2014 1 commit
  15. 20 Feb, 2014 1 commit
  16. 14 Feb, 2014 1 commit