1. 01 Jul, 2021 1 commit
  2. 21 May, 2019 1 commit
  3. 29 Mar, 2019 1 commit
  4. 21 Nov, 2018 1 commit
  5. 12 Nov, 2018 1 commit
  6. 30 Aug, 2018 1 commit
  7. 25 Sep, 2017 1 commit
  8. 03 Aug, 2017 1 commit
  9. 13 Jul, 2017 1 commit
  10. 08 Nov, 2016 1 commit
  11. 26 Oct, 2016 1 commit
    • bbudge's avatar
      [Turbofan] Add concept of FP register aliasing on ARM 32. · 09ab8e6a
      bbudge authored
      - Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
      - Modifies RegisterAllocator to consider aliasing.
      - Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
      - Modifies GapResolver to split wider register moves when interference
      with smaller moves is detected.
      - Modifies MoveOptimizer to handle aliasing.
      - Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
        split moves don't correspond to actual s-registers.
      - Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
        different widths, and moves involving pseudo-s-registers.
      - Adds unit tests for FP operand interference checking and PrepareInsertAfter.
      - Adds more tests of FP for the move optimizer and register allocator.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2410673002
      Cr-Commit-Position: refs/heads/master@{#40597}
      09ab8e6a
  12. 10 Oct, 2016 1 commit
  13. 07 Oct, 2016 1 commit
  14. 06 Oct, 2016 1 commit
  15. 23 Sep, 2016 1 commit
  16. 22 Sep, 2016 1 commit
  17. 13 Sep, 2016 1 commit
  18. 09 Aug, 2016 1 commit
  19. 29 Jul, 2016 1 commit
  20. 01 Jul, 2016 1 commit
    • danno's avatar
      [turbofan]: Support using push instructions for setting up tail call parameters · bd0d9e7d
      danno authored
      This optimizes the passing of stack parameters in function calls.
      
      For some architectures (ia32/x64), using pushes when possible instead
      of bumping the stack and then storing parameters generates much
      smaller code, and in some cases is faster (e.g. when a push of a memory
      location can implement a memory-to-memory copy and thus elide an
      intermediate load. On others (e.g. ARM), the benefit is smaller, where
      it's only possible to elide direct stack pointer adjustment in certain cases
      or combine multiple register stores into a single instruction in other limited
      situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
      and this optimization isn't used at all.
      
      Ideally, this mechanism would be used for both tail calls and normal calls,
      but "normal" calls are currently pretty efficient, and tail calls are very
      inefficient, so this CL sets the bar low for building a new mechanism to
      handle parameter pushing that only needs to raise the bar on tail calls for now.
      
      The key aspect of this change is that adjustment to the stack pointer
      for tail calls (and perhaps later real calls) is an explicit step separate from
      instruction selection and gap resolution, but aware of both, making it possible
      to safely recognize gap moves that are actually pushes.
      
      Review-Url: https://codereview.chromium.org/2082263002
      Cr-Commit-Position: refs/heads/master@{#37477}
      bd0d9e7d
  21. 30 Jun, 2016 1 commit
  22. 29 Jun, 2016 1 commit
  23. 27 Jun, 2016 1 commit
  24. 24 Jun, 2016 1 commit
    • bbudge's avatar
      [Turbofan] Add the concept of aliasing to RegisterConfiguration. · a933b704
      bbudge authored
      - Adds the concept of FP register aliasing to RegisterConfiguration.
      - Changes RegisterAllocator to distinguish between FP representations
      when allocating.
      - Changes LinearScanAllocator to detect interference when FP register
      aliasing is combining, as on ARM.
      - Changes ARM code generation to allow all registers s0 - s31 to be
      accessed.
      - Adds unit tests for RegisterConfiguration, mostly to test aliasing
      calculations.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2086653003
      Cr-Commit-Position: refs/heads/master@{#37251}
      a933b704
  25. 15 Jun, 2016 1 commit
  26. 13 Jun, 2016 1 commit
  27. 04 Feb, 2016 1 commit
    • mtrofin's avatar
      [turbofan] fine grained in-block move optimization · 1ecf58f4
      mtrofin authored
      So far, we've been moving down gaps wholesale. This change moves
      individual move operations instead. This improves some benchmarks,
      and should overall reduce code size, because it improves the chance of
      reducing the number of moves.
      
      For example, there are improvements on x64 in Emscripten (Bullet, in
      particular) , JetStream geomean, Embenchen (zlib).
      
      In the process of making this change, I noticed we can separate the
      tasks performed by the move optimizer, as follows:
      
      - group gaps into 1
      - push gaps down, jumping instructions (these 2 were together before)
      - merge blocks (and then push gaps down)
      - finalize
      
      We can do without a finalization list. This avoids duplicating storage -
      we already have the list of instructions; it also simplifies the logic, since,
      with this change, we may process an instruction's gap twice.
      
      Compile time doesn't regress much (see pathological cases), but we
      may want to avoid the allocations of the few sets used in the new code.
      I'll do that in a subsequent change.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1634093002
      
      Cr-Commit-Position: refs/heads/master@{#33715}
      1ecf58f4
  28. 27 Jan, 2016 1 commit
  29. 25 Jan, 2016 1 commit
    • mtrofin's avatar
      If all the predecessors of a node have, at the last gap, the exact same · 78b55f2e
      mtrofin authored
      moves, we move those to the node, and remove them from the
      predecessors ("merge" them to the common node).
      
      If only some of the moves are common, we don't do anything. This is
      what this change addresses.
      
      The bug linked below should be addressed by this change. The only
      difference in codegen before/after the change that introduced the bug
      was un-merged moves.
      
      BUG=chromium:549262
      LOG=N
      
      Review URL: https://codereview.chromium.org/1527203002
      
      Cr-Commit-Position: refs/heads/master@{#33481}
      78b55f2e
  30. 11 Jan, 2016 1 commit
  31. 23 Dec, 2015 1 commit
    • mtrofin's avatar
      [turbofan] move optimizer - CompressBlock cleanup. · 3f7e96df
      mtrofin authored
      I believe the code reads easier after this change. The original code
      probably dates back to when we had 4 gap positions. Now that there
      are only 2, the logic can be simpler by avoiding a loop and instead
      treating each case explicitly: no gaps; gaps just at end; gaps at start and
      maybe end. That way, it is also  easier to understand how the moves get
      pushed downwards. This is what got me to make this change in the first
      place: trying to work out a finer grained move optimization.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1543973002
      
      Cr-Commit-Position: refs/heads/master@{#33016}
      3f7e96df
  32. 22 Dec, 2015 1 commit
  33. 16 Dec, 2015 2 commits
  34. 29 Oct, 2015 1 commit
    • mtrofin's avatar
      When we split above an instruction (for example because of splintering), · 46878c1d
      mtrofin authored
      we may introduce moves that are redundant in the context of
      moves on subsequent instructions. Currently, we only detect such
      redundancies by allowing moves to skip over Nop instructions (true
      nops, with no input/output). We can also skip over other cases, for
      example over constant definitions (nop with an output), since whatever
      moves happen above it do not influence the instruction's outcome.
      
      We may be able to handle other cases, too - in subsequent CLs.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1422333003
      
      Cr-Commit-Position: refs/heads/master@{#31662}
      46878c1d
  35. 27 Oct, 2015 1 commit
    • danno's avatar
      [turbofan] Create ExplicitOperands to specify operands without virtual registers · f1aa5562
      danno authored
      Up until now, if one wanted to specify an explicit stack location                                                                                                                                                                                                or register as an operand for an instruction, it had to also be
      explicitly associated with a virtual register as a so-called
      FixedRegister or FixedStackSlot.
      
      For the implementation of tail calls, the plan is to use the gap
      resolver needs to shuffle stack locations from the caller to the
      tail-called callee. In order to do this, it must be possible to
      explicitly address operand locations on the stack that are not
      associated with virtual registers.
      
      This CL introduces ExplictOperands, which can specify a specific
      register or stack location that is not associated with virtual
      register. This will allow tail calls to specify the target
      locations for the necessary stack moves in the gap for the tail
      call without the core register allocation having to know about
      the target of the stack moves at all.
      
      In the process this CL:
      * creates a new Operand kind, ExplicitOperand, with which
        instructions can specify register and stack slots without an
        associated virtual register.
      * creates a LocationOperand class from which AllocatedOperand and
        ExplicitOperand are derived and provides a common interface to
        get Register, DoubleRegister and spill slot information.
      * removes RegisterOperand, DoubleRegisterOperand,
        StackSlotOperand and DoubleStackSlotOperand, they are subsumed
        by LocationOperand.
      * addresses a cleanup TODO in AllocatedOperand to reduce the
        redundancy of AllocatedOperand::Kind by using machine_type() to
        determine if an operand corresponds to a general purpose or
        double register.
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1389373002
      
      Cr-Commit-Position: refs/heads/master@{#31603}
      f1aa5562
  36. 06 Aug, 2015 1 commit
  37. 20 May, 2015 1 commit
  38. 29 Apr, 2015 2 commits