1. 28 Jul, 2020 1 commit
  2. 07 Jul, 2020 1 commit
  3. 23 May, 2019 1 commit
  4. 22 May, 2019 1 commit
  5. 15 May, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Use CheckHeapObject only for StoreField. · c7ca8dac
      Benedikt Meurer authored
      Previously we had to use CheckHeapObject in front of every CheckMaps,
      CompareMaps and TransitionElementsKind operation. Now these operators
      request HeapObject representation themselves (requiring for CompareMaps
      and TransitionElementsKind to remove the kNoDeopt property). This means
      we only do CheckHeapObject for StoreField to a field that has HeapObject
      representation.
      
      This not only leads to smaller graphs in the compiler, but also removes
      most uses of the CheckHeapObject operator, which doesn't express a real
      semantic property in the compiler frontend.
      
      Bug: v8:9183, v8:9250
      Refs: nodejs/node#27667
      Change-Id: Ie3d83de69583b1bed6c1c53444bfc97aaef624bb
      Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612902Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61508}
      c7ca8dac
  6. 10 May, 2019 1 commit
  7. 12 Apr, 2019 1 commit
  8. 06 Mar, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Don't access heap in ReduceElementAccess · 4d39e342
      Georg Neis authored
      This CL builds on top of feedback preprocessing. It brokerizes
      all parts of element access reduction and disallows heap access there
      (except for debug tracing).
      
      To make this work without breaking tests (when concurrent inlining is
      enabled):
      - We don't inline functions that weren't serialized for compilation.
      - We don't optimize for constant typed-array receivers when the typed
        array wasn't serialized.
      
      This means that from now on --concurrent-inlining (and thus --future)
      may result in less optimization than the default configuration.
      
      Bug: v8:7790
      Change-Id: I22685258b7d841fc9183bf99775d3f09cd272927
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1495556
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60061}
      4d39e342
  9. 15 Oct, 2018 1 commit
  10. 23 Jul, 2018 1 commit
  11. 17 Jul, 2018 1 commit
  12. 06 Jul, 2018 1 commit
  13. 21 Jun, 2018 1 commit
  14. 23 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce InstanceOfIC to collect rhs feedback. · bcee1406
      Benedikt Meurer authored
      This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
      constant feedback about the right-hand side of instanceof operators,
      including both JSFunction and JSBoundFunction instances. TurboFan then
      uses the feedback to optimize instanceof in places where the right-hand
      side is not a known constant (known to TurboFan).
      
      This addresses the odd performance cliff that we see with instanceof in
      functions with multiple closures. It was discovered as one of the main
      bottlenecks on the uglify-es test in the web-tooling-benchmark. The
      uglify-es test (run in separation) is ~18% faster with this change.
      
      On the micro-benchmark in the tracking bug we go from
      
        instanceofSingleClosure_Const: 69 ms.
        instanceofSingleClosure_Class: 246 ms.
        instanceofMultiClosure: 246 ms.
        instanceofParameter: 246 ms.
      
      to
      
        instanceofSingleClosure_Const: 70 ms.
        instanceofSingleClosure_Class: 75 ms.
        instanceofMultiClosure: 76 ms.
        instanceofParameter: 73 ms.
      
      boosting performance by roughly 3.6x and thus effectively removing the
      performance cliff around instanceof.
      
      Bug: v8:6936, v8:6971
      Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
      Reviewed-on: https://chromium-review.googlesource.com/730686
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48820}
      bcee1406
  15. 09 Aug, 2017 1 commit
  16. 16 Jun, 2017 1 commit
    • jarin's avatar
      [turbofan] Refactor property access building. · 126451d3
      jarin authored
      This is in preparation for lowering monomorphic loads during graph building.
      
      This essentially moves the parts that will be shared to a separate class/file
      (proparty-access-builder.(cc|h)).
      
      I should say that we will not want to do accessor inlining during graph
      building because that would require us to create frame states
      (which is the thing we would like to avoid doing).
      
      Review-Url: https://codereview.chromium.org/2936673005
      Cr-Commit-Position: refs/heads/master@{#45973}
      126451d3