1. 20 Mar, 2017 2 commits
  2. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  3. 16 Mar, 2017 2 commits
  4. 15 Mar, 2017 1 commit
  5. 14 Mar, 2017 2 commits
  6. 09 Mar, 2017 1 commit
  7. 07 Mar, 2017 2 commits
  8. 02 Mar, 2017 1 commit
    • bbudge's avatar
      Implement remaining Boolean SIMD operations on ARM. · 386e5a11
      bbudge authored
      - Implements Select instructions using a single ARM vbsl instruction.
      - Renames boolean machine operators to match renamed S1xN machine types.
      - Implements S1xN vector logical ops, AND, OR, XOR, NOT for ARM.
      - Implements S1xN AnyTrue, AllTrue ops for ARM.
      - Eliminates unused SIMD op categories in opcodes.h.
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2711863002
      Cr-Commit-Position: refs/heads/master@{#43556}
      386e5a11
  9. 28 Feb, 2017 1 commit
  10. 22 Feb, 2017 1 commit
  11. 21 Feb, 2017 2 commits
  12. 14 Feb, 2017 1 commit
  13. 13 Feb, 2017 4 commits
  14. 09 Feb, 2017 3 commits
  15. 08 Feb, 2017 1 commit
  16. 07 Feb, 2017 2 commits
  17. 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
  18. 04 Feb, 2017 1 commit
  19. 02 Feb, 2017 3 commits
  20. 01 Feb, 2017 1 commit
  21. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  22. 27 Jan, 2017 1 commit
    • yangguo's avatar
      [liveedit] reimplement frame restarting. · 3f47c63d
      yangguo authored
      Previously, when restarting a frame, we would rewrite all frames
      between the debugger activation and the frame to restart to squash
      them, and replace the return address with that of a builtin to
      leave that rewritten frame, and restart the function by calling it.
      
      We now simply remember the frame to drop to, and upon returning
      from the debugger, we check whether to drop the frame, load the
      new FP, and restart the function.
      
      R=jgruber@chromium.org, mstarzinger@chromium.org
      BUG=v8:5587
      
      Review-Url: https://codereview.chromium.org/2636913002
      Cr-Commit-Position: refs/heads/master@{#42725}
      3f47c63d
  23. 26 Jan, 2017 2 commits
    • bmeurer's avatar
      [turbofan] Introduce JSCallForwardVarargs operator. · 69747e26
      bmeurer authored
      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.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:5726
      
      Review-Url: https://codereview.chromium.org/2655233002
      Cr-Commit-Position: refs/heads/master@{#42680}
      69747e26
    • 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
  24. 23 Jan, 2017 1 commit
  25. 19 Jan, 2017 1 commit
  26. 18 Jan, 2017 1 commit
    • binji's avatar
      Implement ldrex/strex instructions in ARM simulator · 66ae5f7d
      binji authored
      This CL implements ldrex, ldrexb, ldrexh, strex, strexb, and strexh in the
      Simulator. These instructions provide "exclusive" access, which provides mutual
      exclusion for concurrent threads of execution.
      
      The ARM specification gives some leeway to implementors, but essentially
      describes each processor as having Local Monitor and Global Monitor. The Local
      Monitor is used to check the exclusivity state without having to synchronize
      with other processors. The Global Monitor is shared between processors. We
      model both to make it easier to match behavior with the spec.
      
      When running with multiple OS threads, each thread has its own isolate, and
      each isolate has its own Simulator. The Local Monitor is stored directly on the
      Simulator, and the Global Monitor is stored as a lazy singleton. The Global
      Monitor maintains a linked-list of all Simulators.
      
      All loads/stores (even non-exclusive) are guarded by the Global Monitor's mutex.
      
      BUG=v8:4614
      
      Review-Url: https://codereview.chromium.org/2006183004
      Cr-Commit-Position: refs/heads/master@{#42481}
      66ae5f7d