1. 17 Jun, 2021 2 commits
  2. 14 Oct, 2020 1 commit
  3. 20 Mar, 2020 1 commit
  4. 24 May, 2019 1 commit
  5. 23 May, 2019 1 commit
  6. 21 May, 2019 1 commit
  7. 17 May, 2019 1 commit
  8. 16 May, 2019 2 commits
  9. 15 Feb, 2019 1 commit
  10. 20 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove a lot of dead intrinsics/runtime functions. · 44c24bf8
      Benedikt Meurer authored
      The following runtime functions (and their intrinsic counter parts) are
      completely unused/obsolete by now
      
        - %ToInteger
        - %GeneratorGetInputOrDebugPos
      
      and in addition the intrinsics for %_ToNumber and %_IsJSProxy are also
      dead (according to code coverage and manual verification), so drop them
      as well (their runtime function counterparts are still somewhat used).
      
      Bug: v8:8015
      Change-Id: I60d53762dd9717fb43de38cb490b46676c467212
      Reviewed-on: https://chromium-review.googlesource.com/1235923Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56076}
      44c24bf8
  11. 14 Sep, 2018 1 commit
  12. 09 Aug, 2018 1 commit
    • jgruber's avatar
      [builtins] Fix argument order inconsistency in HasProperty · 3c1f40de
      jgruber authored
      The HasProperty builtin differed in its expected argument order from
      the HasProperty runtime function. Like all other related spec
      primitives (e.g.: GetProperty, SetProperty, DeleteProperty), it should
      take {object} as the first argument and {key} as the second.
      
      This CL changes the builtin and all related spots to use the correct
      order.
      
      There was also a tricky bug in interpreter intrinsic rewriting, which
      assumes (but does not verify) that the argument order between runtime
      function and builtin is identical. Besides cctests, HasProperty
      intrinsic rewriting seems to be dead code.
      
      Bug: v8:8036
      Change-Id: Ia669fd6f5c73a30df4e4607064603be759ced392
      Reviewed-on: https://chromium-review.googlesource.com/1167297
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55022}
      3c1f40de
  13. 23 Jul, 2018 1 commit
  14. 15 Feb, 2018 1 commit
  15. 13 Dec, 2017 1 commit
  16. 15 Nov, 2017 1 commit
  17. 18 Oct, 2017 1 commit
  18. 30 Mar, 2017 1 commit
  19. 23 Feb, 2017 1 commit
  20. 20 Jan, 2017 1 commit
  21. 09 Jan, 2017 1 commit
  22. 22 Dec, 2016 1 commit
  23. 21 Dec, 2016 1 commit
  24. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored
      There are only a few occasions where we allocate a register in an outer
      expression allocation scope, which makes the costly free-list approach
      of the BytecodeRegisterAllocator unecessary. This CL replaces all
      occurrences with moves to the accumulator and stores to a register
      allocated in the correct scope. By doing this, we can simplify the
      BytecodeRegisterAllocator to be a simple bump-pointer allocator
      with registers released in the same order as allocated.
      
      The following changes are also made:
       - Make BytecodeRegisterOptimizer able to use registers which have been
         unallocated, but not yet reused
       - Remove RegisterExpressionResultScope and rename
         AccumulatorExpressionResultScope to ValueExpressionResultScope
       - Introduce RegisterList to represent consecutive register
         allocations, and use this for operands to call bytecodes.
      
      By avoiding the free-list handling, this gives another couple of
      percent on CodeLoad.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2369873002
      Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  25. 18 Aug, 2016 1 commit
  26. 11 Jul, 2016 1 commit
  27. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored
      Introduce a new machine operator Float64Pow that for now is backed by
      the existing MathPowStub to start the unification of Math.pow, and at
      the same time address the main performance issue that TurboFan still has
      with the imaging-darkroom benchmark in Kraken.
      
      Also migrate the Math.pow builtin itself to a TurboFan builtin and
      remove a few hundred lines of hand-written platform code for special
      handling of the fullcodegen Math.pow version.
      
      BUG=v8:3599,v8:5086,v8:5157
      
      Review-Url: https://codereview.chromium.org/2103733003
      Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  28. 23 Jun, 2016 1 commit
  29. 22 Jun, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add intrinsics called as stubs. · 485e7751
      rmcilroy authored
      Adds support for intrinsics which can be called as stubs. Namely:
       - HasProperty
       - MathPow
       - NewObject
       - NumberToString
       - RegExpConstructResult
       - RegExpExec
       - Substring
       - ToString
       - ToName
       - ToLength
       - ToNumber
       - ToObject
      
      Also adds interface descriptors for stub calls which have arguments
      passed on the stack.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2051573002
      Cr-Commit-Position: refs/heads/master@{#37185}
      485e7751
  30. 03 Jun, 2016 1 commit
  31. 27 May, 2016 1 commit
  32. 22 Mar, 2016 1 commit