Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 15 Jun, 2016 1 commit
  5. 10 May, 2016 1 commit
    • bbudge's avatar
      [turbofan] Rename floating point register / slot methods. · 8c8600db
      bbudge authored 
      Renames IsDouble* predicates to IsFP*.
Adds specific IsFloat*, IsDouble*, and IsSimd128* predicates.
Adds specific GetFloatRegister, GetDoubleRegister, and
GetSimd128Register methods.

This is mostly a mechanical renaming of IsDouble* to IsFP* methods.

This shouldn't change code generation at all. All fp registers are still
treated as double registers.

LOG=N
BUG=v8:4124

Review-Url: https://codereview.chromium.org/1959763002
Cr-Commit-Position: refs/heads/master@{#36146}
      8c8600db
  7. 29 Feb, 2016 1 commit
  9. 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
  11. 20 May, 2015 1 commit
  13. 29 Apr, 2015 3 commits
  15. 15 Apr, 2015 1 commit
    • dcarney's avatar
      [turbofan] cleanup ParallelMove · 00aec790
      dcarney authored 
      - make ParallelMove into a ZoneVector, removing an annoying level of indirection
- make MoveOperands hold InstructionOperands instead of pointers, so there's no more operand aliasing for moves
- opens up possibility of storing MachineType in allocated operands

R=bmeurer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1081373002

Cr-Commit-Position: refs/heads/master@{#27842}
      00aec790
  17. 09 Apr, 2015 1 commit
    • dcarney's avatar
      [turbofan] cleanup InstructionOperand a little · 07ff6d9f
      dcarney authored 
      - ConstantOperand was using a too-small field too store its virtual register
- drop ConvertTo, replace it with simple copy
- split AllocatedOperand off from Immediate and Constant to make assignment clearer, also paving the way for small Immediates
- put zone first in *Operand::New
- driveby: drop delayed ssa deconstruction experiment

R=titzer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1050803002

Cr-Commit-Position: refs/heads/master@{#27692}
      07ff6d9f
  19. 04 Aug, 2014 1 commit
  21. 31 Jul, 2014 1 commit
  23. 30 Jul, 2014 1 commit