1. 20 Feb, 2018 1 commit
  2. 23 Jan, 2018 1 commit
  3. 06 Nov, 2017 1 commit
    • Toon Verwaest's avatar
      Drop custom accessor deoptimization support · c82cd313
      Toon Verwaest authored
      Previously StaNamedProperty and StaKeyedProperty were in a weird state where
      they claimed to not touch the accumulator, but actually did in case they were
      deopted in the middle. A frame was added in the middle to overwrite the 
      accumulator again with the right value before returning from the setter, using
      a lot of complexity in the deoptimizer.
      
      This changes those instructions to be marked as writing to the accumulator
      (e.g., the result of the setter), and uses to manually store and reload into
      the accumulator the value being stored.
      
      If we want to avoid the additional bytecodes, we could make sure that bytecodes
      that claim to leave the accumulator alone don't deopt back to Advance/Dispatch
      but LoadAccumulatorWithValue/Advance/Dispatch. That's in a way similar to what
      happened before this CL, but I believe could be implemented much simpler.
      
      
      Bug: 
      Change-Id: I4850a690ef5a30976701d0e050951faa46fd1c18
      Reviewed-on: https://chromium-review.googlesource.com/753487Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49159}
      c82cd313
  4. 31 Jul, 2017 1 commit
  5. 13 Jul, 2017 1 commit
  6. 30 Jun, 2017 1 commit
  7. 22 Jun, 2017 1 commit
  8. 14 Jun, 2017 1 commit
  9. 07 Jun, 2017 1 commit
    • danno's avatar
      Inline Array.prototype.forEach in TurboFan · 90c3a2d5
      danno authored
      This CL contains a few pieces:
      
      - A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
        graphs, which--when triggered--swizzle the values in the the FrameState to be
        parameters to a typically TF-generated builtin that resumes execution to finish
        the slow-case functionality.
      - Continuation builtins that have special handling in the deoptimizer and their own
        new frame type to ensure that the values they need to begin executing can be stashed
        away and restored immediately before the builtin is called via a trampoline that runs
        when the continuation builtin's frame execution resumes.
      - An implementation of Array.prototype.forEach in TurboFan that can be used to
        inline it. The inlined forEach implementation uses the checkpoints mechanism
        described above to deopt in the middle of the forEach in the cases that optimization
        invariants are violated. There is a slightly different continuation stub for each
        deopt point in the forEach implementation to ensure the correct side-effects, i.e.
        that the deopt of the builtin isn't programmatically observable.
      
      Review-Url: https://codereview.chromium.org/2803853005
      Cr-Commit-Position: refs/heads/master@{#45764}
      90c3a2d5
  10. 22 May, 2017 1 commit
  11. 09 Jan, 2017 1 commit
  12. 01 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for accessor inlining. · 35a195e1
      bmeurer authored
      Allow inlining of getters and setters into TurboFan optimized code.
      This just adds the basic machinery required to essentially inline
      the setter and getter dispatch code for the (keyed) load/store ICs.
      There'll be follow up CLs to also actually inline some of the interesting
      accessor functions itself, like the byteLength and friends for the
      TypedArrays.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2198473002
      Cr-Commit-Position: refs/heads/master@{#38192}
      35a195e1
  13. 09 Mar, 2016 1 commit
  14. 05 Jan, 2016 1 commit
    • sigurds's avatar
      [turbofan] Deopt support for escape analysis · 3b473d7a
      sigurds authored
      Deopt support is added on two levels. On the IR level,
      a new ObjectState node is added, which represenents an
      object to be materialized. ObjectState nodes appear as
      inputs of FrameState and StateValues nodes. On the
      instruction select/code-generation level, the
      FrameStateDescriptor class handles the nesting
      introduced by ObjectState, and ensures that deopt code
      with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
      generated similarly to what crankshaft's escape
      analysis does.
      
      Two unittests test correctness of the IR level implementation.
      
      Correctness for instruction selection / code generation
      is tested by mjsunit tests.
      
      R=jarin@chromium.org,mstarzinger@chromium.org
      BUG=v8:4586
      LOG=n
      
      Review URL: https://codereview.chromium.org/1485183002
      
      Cr-Commit-Position: refs/heads/master@{#33115}
      3b473d7a
  15. 18 Dec, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Generate valid FrameStates in the Bytecode Graph Builder. · 32211800
      rmcilroy authored
      Adds FrameState nodes to graphs built by the Bytecode Graph Builder, in
      preparation for adding deopt support. Also adds a new
      FrameStateType::kInterpretedFunction to allow for specialized deopt
      stack translation for interpreted frames. Finally adds support for
      disabling typed lowering of binary ops, since the current approach
      relies on a FrameState hack which does not apply to interpreted frames
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1514413002
      
      Cr-Commit-Position: refs/heads/master@{#32964}
      32211800
  16. 12 Nov, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Initial support for constructor call inlining. · 11d5d09c
      mstarzinger authored
      This implements a first version of support for constructor call inlining
      in the inlining machinery. For now we can only inline calls where the
      actual constructor and the original constructor coincide (i.e. no super
      constructor calls). Note that the target of a super constructor call is
      loaded with a runtime call, so there is no way for it to be constant
      promoted at the moment.
      
      R=bmeurer@chromium.org
      BUG=v8:4544
      LOG=n
      
      Review URL: https://codereview.chromium.org/1435873002
      
      Cr-Commit-Position: refs/heads/master@{#31954}
      11d5d09c
  17. 12 Aug, 2015 1 commit
    • mstarzinger's avatar
      Remove inline header includes from non-inline headers (1). · 00a07bc1
      mstarzinger authored
      This tries to remove includes of "-inl.h" headers from normal ".h"
      headers, thereby reducing the chance of any cyclic dependencies and
      decreasing the average size of our compilation units.
      
      Note that this change still leaves 7 violations of that rule in the
      code. However there now is the "tools/check-inline-includes.sh" tool
      detecting such violations.
      
      R=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1283033003
      
      Cr-Commit-Position: refs/heads/master@{#30125}
      00a07bc1
  18. 23 Jun, 2015 1 commit
  19. 28 May, 2015 1 commit
  20. 15 May, 2015 1 commit
  21. 11 May, 2015 1 commit