1. 10 May, 2022 1 commit
  2. 06 Apr, 2022 1 commit
  3. 25 Mar, 2022 1 commit
  4. 21 Mar, 2022 1 commit
  5. 20 Jan, 2022 1 commit
  6. 01 Dec, 2021 1 commit
  7. 19 Oct, 2021 1 commit
  8. 12 Aug, 2021 1 commit
  9. 20 Jul, 2021 1 commit
  10. 08 Jul, 2021 1 commit
    • Georg Neis's avatar
      Optimize JSCallWithArrayLike with diamond speculation when probable arguments... · 90a24303
      Georg Neis authored
      Optimize JSCallWithArrayLike with diamond speculation when probable arguments list is empty literal array
      
      The JSCallWithArraylike can be replaced with a JSCall if its probable arguments list is empty literal array. This replacement will introduce a deoptimization check to make sure the length of arguments list is 0 at runtime.
      
      This CL change this optimization to a diamond speculation which may help avoid deoptimization once and keep the fast path. This change may benefit a following usecase,
      
      function calcMax(testArray) {
           Array.max = function(array) {
               return Math.max.apply(Math, array);
           };
      
           var result = [];
           for (var i = 0; i < testArray.length - 3; i++) {
               var positiveNumbers = [];
               for (var j = 0; j < 3; j++) {
                   if (testArray[i + j] > 0) {
                       positiveNumbers.push(testArray[i + j]);
                   }
               }
               result.push(Array.max(positiveNumbers));
           }
           return result;
       }
      
       testArray = [-1, 2, 3, -4, -5, -6, -7, -8, -9, 10];
      
       for (var i = 0; i < 1000000; i++) {
           calcMax(testArray);
       }
      
      Bug: v8:9974
      Change-Id: I595627e2fd937527350c8f8652d701c791b41dd3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967757
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75636}
      90a24303
  11. 30 Jun, 2021 1 commit
  12. 26 Apr, 2021 1 commit
  13. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  14. 23 Feb, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm][cleanup] Increase GraphAssembler infra usage in WasmGraphBuilder · 825cb671
      Manos Koukoutos authored
      WasmGraphBuilder often failed to use GraphAssembler infrastructure and
      went with directly invoking graph()->NewNode(). This made the code more
      verbose, especially in cases where effect() and control() had to be
      passes directly to NewNode().
      This CL eliminates these invocations in obvious cases. It does not try
      to refactor complicated code with branches, diamond patterns, etc.
      
      Additional changes:
      - Define a few more operators in GraphAssembler.
      - Move Branch() helper in WasmGraphAssembler.
      - Define NumberConstant() helper in WasmGraphAssembler.
      - Define Merge() helper with varargs in WasmGraphBuilder.
      - Omit IntPtrConstant() wrapper for constant offsets of Load and Store.
      
      Change-Id: I571d5286be8881504cb2060195fbd181d1fce67d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712804Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72975}
      825cb671
  15. 22 Feb, 2021 1 commit
  16. 15 Feb, 2021 1 commit
  17. 11 Jan, 2021 1 commit
  18. 16 Dec, 2020 1 commit
  19. 02 Dec, 2020 1 commit
  20. 01 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [Turboprop] Move deoptimizations for dynamic map checks into builtin. · b6643320
      Ross McIlroy authored
      In order to reduce the codegen size of dynamic map checks, add the
      ability to have an eager with resume deopt point, which can call
      a given builitin to perform a more detailed check than can be done
      in codegen, and then either deoptimizes itself (as if the calling
      code had performed an eager deopt) or resumes execution in the
      calling code after the check.
      
      In addition, support for adding extra arguments to a
      deoptimization continuation is added to enable us to pass the
      necessary arguments to the DynamicMapChecks builtin.
      
      Finally, a trampoline is added to the DynamicMapChecks which saves
      the registers that might be clobbered by that builtin, to avoid
      having to save them in the generated code. This trampoline also
      performs the deoptimization based on the result of the
      DynamicMapChecks builtin.
      
      In order to ensure both the trampoline and DynamicMapChecks
      builtin have the same call interface, and to limit the number
      of registers that need saving in the trampoline, the
      DynamicMapChecks builtin is moved to be a CSA builtin with a
      custom CallInterfaceDescriptor, that calls an exported Torque
      macro that implements the actual functionality.
      
      All told, this changes the codegen for a monomorphic dynamic
      map check from:
          movl rbx,<expected_map>
          cmpl [<object>-0x1],rbx
          jnz <deferred_call>
         resume_point:
          ...
         deferred_call:
          <spill registers>
          movl rax,<slot>
          movq rbx,<object>
          movq rcx,<handler>
          movq r10,<DynamicMapChecks>
          call r10
          cmpq rax,0x0
          jz <restore_regs>
          cmpq rax,0x1
          jz <deopt_point_1>
          cmpq rax,0x2
          jz <deopt_point_2>
          int3l
         restore_regs:
          <restore_regs>
          jmp <resume_point>
          ...
         deopt_point_1:
          call Deoptimization_Eager
         deopt_point_2:
          call Deoptimization_Bailout
      
      To: movl rax,<slot>
          movl rcx,<expected_map>
          movq rdx,<handler>
          cmpl [<object>-0x1],rcx
          jnz <deopt_point>
         resume_point:
          ...
         deopt_point:
          call DynamicMapChecksTrampoline
          jmp <resume_point>
      
      BUG=v8:10582
      
      Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71545}
      b6643320
  21. 27 Nov, 2020 1 commit
  22. 26 Nov, 2020 1 commit
  23. 06 Oct, 2020 1 commit
  24. 02 Oct, 2020 1 commit
  25. 29 Sep, 2020 1 commit
  26. 28 Sep, 2020 1 commit
  27. 10 Sep, 2020 2 commits
    • Jakob Gruber's avatar
      [nci] Implement tier-up (part 3, spawn task & install) · 608018e5
      Jakob Gruber authored
      This is the final part of the tier-up commit series. It implements:
      
      - A prologue in NCI code objects that checks and acts upon the
      optimization marker.
      - Currently, handling is deferred to the InterpreterEntryTrampoline
      but this will change in the future.
      - The lifecycle is otherwise like Ignition-to-Turbofan; the runtime
      profiler marks a function for optimization, the next call to that
      function triggers optimization by calling into runtime, and the
      finished code object is installed both on the JSFunction and the
      optimized code cache.
      - The feedback vector's kOptimizedCodeWeakOrSmiOffset slot is
      currently reused for the mid-to-top tier up.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:8888
      Change-Id: Iff50b05ddcc68b25d7ed0f1e0d20af076a1522a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361466Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69808}
      608018e5
    • Sathya Gunasekaran's avatar
      [turboprop] Unroll loop in the dynamic map checks operator · 9c67790b
      Sathya Gunasekaran authored
      The dynamic map checks operator loads the feedback vector and performs
      map checks against each map and handler entry in the feedback against
      the incoming map and handler.
      
      Instead of emitting code to iterate over this feedback vector at
      runtime, we unroll this loop at compile time.
      
      The generated code is similar to this pseudocode:
      
        length = feedback_slot.length
        if length >= 4: goto labels[3]
        if length == 3: goto labels[2]
        if length == 2: goto labels[1]
        if length == 1: goto labels[0]
      
        labels[3]:
          map = load(feedback_slot, 6)
          if incoming_map == map goto handler_check(7)
          goto labels[2]
        labels[2]:
          map = load(feedback_slot, 4)
          if incoming_map == map goto handler_check(5)
          goto labels[1]
        labels[1]:
          map = load(feedback_slot, 2)
          if incoming_map == map goto handler_check(3)
          goto labels[0]
        labels[0]:
          map = load(feedback_slot, 0)
          if incoming_map == map goto handler_check(1)
          bailout
      
        handler_check (index):
          handler = load(feedback_slot, index)
          if incoming_handler ==  handler goto done
          deoptimize
      
      Bug: v8:10582, v8:9684
      Change-Id: I64d64ff8eda664e4d476bf1b2612e26a344e98a6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339960
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69797}
      9c67790b
  28. 24 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      Improve usability of GraphAssembler's Unreachable() · e02e5107
      Jakob Gruber authored
      Prior to this CL, one had to artificially insert a
      basic-block-terminating node after Unreachable. The common pattern was
      
       Unreachable();
       Goto(&some_label);  // Never reached but generates useless code.
      
      This CL improves usability by automatically merging Unreachable nodes
      to the end node, and terminating current effect/control. The updated
      pattern is just
      
       Unreachable();
      
      or in cases where Turboprop must maintain a schedule:
      
       Unreachable(&some_label);
      
      Bug: v8:8888
      Change-Id: I26a0b11b5e67252a6dc3584ae09ed06370f1eacc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362690
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69531}
      e02e5107
  29. 11 Aug, 2020 1 commit
  30. 22 Jul, 2020 1 commit
  31. 20 Jul, 2020 1 commit
  32. 15 Jul, 2020 1 commit
  33. 30 Jun, 2020 1 commit
  34. 25 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add feedback input to more nodes kinds · 5d417c0d
      Jakob Gruber authored
      ... and extend JS node wrapper functionality.
      
      Node wrappers now have accessors for value inputs and
      context/control/effect/frame-state inputs. Accessors are typed,
      although types aren't very meaningful so far (in current examples we
      only distinguish between Object/HeapObject).
      
      The following node kinds now take an additional feedback vector input,
      and use the new node wrapper functionality above:
      
      - CloneObject
      - CreateLiteralArray
      - CreateLiteralObject
      - CreateLiteralRegExp
      - GetIterator
      - GetTemplateObject
      - HasProperty
      - LoadProperty
      - StoreProperty
      
      Bug: v8:8888
      Change-Id: I1eb33c078b11725a72ec983bbaa848b9a3c7b0d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259936
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68538}
      5d417c0d
  35. 22 Jun, 2020 1 commit
  36. 08 Jun, 2020 1 commit
  37. 15 May, 2020 1 commit
  38. 07 May, 2020 1 commit
  39. 29 Apr, 2020 1 commit