1. 07 Mar, 2017 1 commit
  2. 01 Mar, 2017 1 commit
    • zhengxing.li's avatar
      X87: [turbofan] Introduce JSCallForwardVarargs operator. · 6cff2ddf
      zhengxing.li authored
        port 69747e26(r42680)
      
        original commit message:
        We turn a JSCallFunction node for
      
          f.apply(receiver, arguments)
      
        into a JSCallForwardVarargs node, when the arguments refers to the
        arguments of the outermost optimized code object, i.e. not an inlined
        arguments, and the apply method refers to Function.prototype.apply,
        and there's no other user of arguments except in frame states.
      
        We also replace the arguments node in the graph with a marker for
        the Deoptimizer similar to Crankshaft to make sure we don't materialize
        unused arguments just for the sake of deoptimization. We plan to replace
        this with a saner EscapeAnalysis based solution soon.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2681783002
      Cr-Commit-Position: refs/heads/master@{#43516}
      6cff2ddf
  3. 21 Feb, 2017 1 commit
    • bbudge's avatar
      [V8] Implement SIMD Boolean vector types to allow mask registers. · 9fe0b4c7
      bbudge authored
      - Adds new machine types SimdBool4/8/16 for the different boolean vector types.
      - Adds a kSimdMaskRegisters flag for each platform. These are all false for now.
      - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle
        opcodes from the Boolean types. These are unlikely to be well supported natively,
        and can be synthesized using Select.
      - Changes the signature of Relational opcodes to return boolean vectors.
      - Changes the signature of Select opcodes to take boolean vectors.
      - Updates the ARM implementation of Relational and Select opcodes.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2700813002
      Cr-Commit-Position: refs/heads/master@{#43348}
      9fe0b4c7
  4. 14 Feb, 2017 1 commit
  5. 13 Feb, 2017 4 commits
  6. 09 Feb, 2017 3 commits
  7. 07 Feb, 2017 1 commit
  8. 06 Feb, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root feedback vectors at function literal site. · aea3ce3d
      mvstanton authored
      TypeFeedbackVectors are strongly rooted by a closure. However, in modern
      JavaScript closures are created and abandoned more freely. An important
      closure may not be present in the root-set at time of garbage collection,
      even though we've cached optimized code and use it regularly. For
      example, consider leaf functions in an event dispatching system. They may
      well be "hot," but tragically non-present when we collect the heap.
      
      Until now, we've relied on a weak root to cache the feedback vector in
      this case. Since there is no way to signal intent or relative importance,
      this weak root is as susceptible to clearing as any other weak root at
      garbage collection time.
      
      Meanwhile, the feedback vector has become more important. All of our
      ICs store their data there. Literal and regex boilerplates are stored there.
      If we lose the vector, then we not only lose optimized code built from
      it, we also lose the very feedback which allowed us to create that optimized
      code. Therefore it's vital to express that dependency through the root
      set.
      
      This CL does this by creating a strong link to a feedback
      vector at the instantiation site of the function closure.
      This instantiation site is in the code and feedback vector
      of the outer closure.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2674593003
      Cr-Commit-Position: refs/heads/master@{#42953}
      aea3ce3d
  9. 02 Feb, 2017 2 commits
  10. 26 Jan, 2017 1 commit
    • mstarzinger's avatar
      [deoptimizer] Preserve double bit patterns correctly. · 7376e12e
      mstarzinger authored
      This makes sure that the deoptimizer preserves the exact bit pattern of
      floating-point values (both 32-bit and 64-bit) up to the point where a
      potential {HeapNumber} is allocated. It in turn allows us to correctly
      recognize the {hole_nan_value} when stored into a {FixedDouleArray}.
      
      R=jarin@chromium.org
      TEST=mjsunit/regress/regress-crbug-684208
      BUG=chromium:684208
      
      Review-Url: https://codereview.chromium.org/2652303002
      Cr-Commit-Position: refs/heads/master@{#42679}
      7376e12e
  11. 24 Jan, 2017 1 commit
  12. 19 Jan, 2017 1 commit
  13. 17 Jan, 2017 1 commit
  14. 16 Jan, 2017 1 commit
  15. 12 Jan, 2017 2 commits
  16. 11 Jan, 2017 3 commits
  17. 10 Jan, 2017 4 commits
  18. 05 Jan, 2017 1 commit
  19. 03 Jan, 2017 1 commit
  20. 27 Dec, 2016 1 commit
  21. 19 Dec, 2016 1 commit
  22. 01 Dec, 2016 1 commit
  23. 30 Nov, 2016 1 commit
  24. 29 Nov, 2016 1 commit
  25. 22 Nov, 2016 2 commits
  26. 18 Nov, 2016 1 commit
  27. 16 Nov, 2016 1 commit