Skip to content

V
V8
Switch branch/tag
  1. 01 Mar, 2016 1 commit
  3. 16 Feb, 2016 1 commit
  5. 15 Feb, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove the function reload hack for OSR. · 359ba8e0
      bmeurer authored 
      Initially we were unable to address certain stack slots in the callee
part of the frame, including the function marker, therefore we had to
hack a reload of the function register into the OSR prologue. Now that
we are able to address all stack slots, we no longer need this hack.

R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33974}
      359ba8e0
  7. 10 Feb, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make InterpreterAssembler a subclass of CodeStubAssembler. · d1c28849
      rmcilroy authored 
      Moves InterpreterAssembler out of the compiler directory and into the
interpreter directory. Makes InterpreterAssembler as subclass of
CodeStubAssembler.

As part of this change, the special bytecode dispatch linkage type
is removed and instead we use a InterfaceDispatchDescriptor and
a normal CodeStub linkage type.

Removes a bunch of duplicated logic in InterpreterAssembler and
instead uses the CodeStubAssembler logic. Refactors Interpreter
with these changes.

Modifies CodeStubAssembler to add the extra operations required
by the Interpreter (extra call types, raw memory access and some extra
binary ops). Also adds the ability for subclasses to add extra
prologue and epilogue operations around calls, which is required
for the Interpreter.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33873}
      d1c28849
  9. 01 Feb, 2016 1 commit
  11. 18 Jan, 2016 1 commit
  13. 08 Jan, 2016 1 commit
  15. 10 Dec, 2015 1 commit
    • jarin's avatar
      [turbofan] Make MachineType a pair of enums. · bb2a830d
      jarin authored 
      MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic

Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.

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

Cr-Commit-Position: refs/heads/master@{#32738}
      bb2a830d
  17. 03 Dec, 2015 2 commits
  19. 02 Dec, 2015 1 commit
    • danno's avatar
      [stubs] A new approach to TF stubs · 3e7e3ed7
      danno authored 
      * Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32508}
      3e7e3ed7
  21. 24 Nov, 2015 1 commit
    • danno's avatar
      [turbofan] Add general support for sp-based frame access · 51669873
      danno authored 
      Some highlights of this CL:
* Refactor the mutable state out of Frame into FrameAccessState,
  which is maintained and updated during code generation to
  record whether sp- or fp-based frame access is currently active
  and how deep the stack on top of the frame is.
* The operand resultion in linkage.cc now uses FrameAccessState
  to determine how to generate frame-accessing operands.
* Update all platforms to accurately track additionally pushed
  stack slots (e.g. arguments for calls) in the FrameAccessState.
* Add a flag, --turbo_sp_frame_access, which forces all frame
  access to be sp-based whenever possible. This will likely never
  be used in production, but for testing it's useful in verifying
  that the stack-tracking of each platform maintained in the
  FrameAccessState is correct.
* Use sp-based frame access for gap resolving before tail
  calls. This will allow for slightly more efficient restoration
  of the frame pointer in the tail call in a later CL.
* Remove most ad hoc groping into CallDescriptors to
  determine if a frame is needed, instead consistently use
  predicates like needs_frame(), IsCFunctionCall() and
  IsJSFunctionCall().

BUG=v8:4076
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32234}
      51669873
  23. 20 Nov, 2015 1 commit
  25. 19 Nov, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Make new.target explicit in JSCallDescriptor. · 0227857d
      mstarzinger authored 
      This adds an explicit parameter to the call descriptor having kind
kJSCallFunction representing the new.target value. Note that for now
this parameter is not yet passed in and hence cannot be used yet. Also
contains some refactoring of how parameter index value are calculated,
establishing Linkage as the central point for such index computations.

This is a preparatory CL to allows us passing new.target in a register
instead of via a side-channel through the construct stub frame.

R=bmeurer@chromium.org
BUG=v8:4544
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#32112}
      0227857d
  27. 13 Nov, 2015 2 commits
    • mtrofin's avatar
      [turbofan] Spill rsi and rdi in their existing locations. · 20f3a077
      mtrofin authored 
      We push the context and the js function onto the stack as part of the
frame construction. The register allocator is presented with virtual
registers for the above as defined from their corresponding registers. It
then goes on to spilling them somewhere else on the stack.

This means each function spends two redundant spills and two
unnecessary stack slots.

This change addresses this issue.

We present these parameters (context and function) to the register
allocator as an UnallocatedOperand having a "secondary storage". The
secondary storage is then associated to the live range as its
spill operand. We capture the definition of the live range so that we can
then commit the spill (in this case, eliminate) through a variation of the
mechanics of the CommitAssignment phase.

The register allocator validator also needed update to understand
UnallocatedOperands with a secondary storage.

The change renames the SpillAtDefinitionList and related APIs to better
capture their intent - the old names suggested spills happened upon
calling. In reality, potential spill locations were thus recorded, and later
committed (or not, in certain cases) after register allocation.

BUG= v8:4548
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31988}
      20f3a077
    • danno's avatar
      [turbofan] Better and more sane support for tail calls · ff283f7d
      danno authored 
      * Limit triggering of tail calls to explicit use of a new inline runtime
  function %_TailCall. %_TailCall works just like %_Call except for using
  tail-calling mechanics (currently only in TF).
* Remove hack that recognized some specific usages of %_Call and converted them
  into tail calls.
* Support tail calls for all calls where the number of callee stack parameters
  is less than or equal to the number of caller stack parameters.
* Use the gap resolver to swizzle parameters and registers to tail calls.

BUG=v8:4076
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31987}
      ff283f7d
  29. 04 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Implement the call protocol properly for direct calls. · 30aca03a
      bmeurer authored 
      The callees are expected to properly set the number of actual
arguments passed to the callee, which is now represented correctly
in the TurboFan graphs by a new Parameter right before the context
Parameter.  Currently this is only being used for outgoing calls.

Note that this requires disabling two of the TF code stub tests,
because of the JavaScript graphs are not automagically compatible
with abitrary (incoming) code stub interface descriptors.  If we
want to support JS code stubs at all, then we need to find a sane
way to feed in this information.

Drive-by-fix: Don't insert a direct call to a classConstructor.

R=mstarzinger@chromium.org
BUG=v8:4413, v8:4428
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31789}
      30aca03a
  31. 19 Oct, 2015 1 commit
    • jarin's avatar
      [turbofan] Introduce lazy bailout, masked as a call. · f9a9c6be
      jarin authored 
      This introduces an explicit lazy bailout. It is wrapped in the call
node, mostly because the lazy deoptimization processing is married
to the call processing in the instruction selector and the code generator.

It is still a terrible hack.

R=bmeurer@chromium.org,mstarzinger@chromium.org
BUG=chromium:543994,v8:4195
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#31353}
      f9a9c6be
  33. 08 Oct, 2015 1 commit
  35. 10 Sep, 2015 1 commit
    • bmeurer's avatar
      [runtime] Move binary operator fallbacks into the runtime. · a1b2ec60
      bmeurer authored 
      Replace the ADD, SUB, etc. builtins with proper runtime implementations,
and expose them as runtime calls that can be used by the code stubs and
the interpreter (for now).

Also remove all the support runtime functions for ADD, SUB and friends,
namely %NumberAdd, %NumberSub, and so on.

R=mstarzinger@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg

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

Cr-Commit-Position: refs/heads/master@{#30680}
      a1b2ec60
  37. 24 Aug, 2015 1 commit
  39. 18 Aug, 2015 1 commit
  41. 13 Aug, 2015 1 commit
  43. 11 Aug, 2015 2 commits
  45. 10 Aug, 2015 1 commit
  47. 07 Aug, 2015 2 commits
  49. 31 Jul, 2015 1 commit
  51. 30 Jul, 2015 2 commits
  53. 23 Jul, 2015 1 commit
    • rmcilroy's avatar
      [interpreter] Add basic framework for bytecode handler code generation. · 7877c4e0
      rmcilroy authored 
      Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.

Currently only two simple bytecodes are supported: LoadLiteral0 and Return.

BUG=v8:4280
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#29814}
      7877c4e0
  55. 13 Jul, 2015 1 commit
  57. 06 Jul, 2015 1 commit
  59. 02 Jul, 2015 1 commit
  61. 30 Jun, 2015 1 commit
  63. 26 Jun, 2015 1 commit
  65. 25 Jun, 2015 1 commit
  67. 28 May, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Introduce prediction for exception handlers. · d8b94f34
      mstarzinger authored 
      This introduces a conservative prediction for each exception handler
whether it will locally catch an exception or re-throw it to outside
the code bondaries. It will allow for a more intuitive prediction of
whether an exception is considered "caught" or "uncaught".

R=bmeurer@chromium.org,yangguo@chromium.org
BUG=chromium:492522
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#28681}
      d8b94f34
  69. 30 Apr, 2015 1 commit
    • svenpanne's avatar
      Detect simple tail calls · 4b122b75
      svenpanne authored 
      This CL contains the first steps towards tail call optimization:

  * Structurally detect tail calls during instruction selection,
    looking for special return/call combinations.

  * Added new architecture-specific instructions for tail calls which
    jump instead of call and take care of frame adjustment.

  * Moved some code around.

Currently we restrict tail calls to callees which only use registers
for arguments/return value and to call sites which are explicitly
marked as being OK for tail calls. This excludes, among other things,
call sites in sloppy JS functions and our IC machinery (both need in
general to be able to access the caller's frame).

All this is behind a flag --turbo-tail-calls, which is currently off
by default, so it can easily be toggled.

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

Cr-Commit-Position: refs/heads/master@{#28150}
      4b122b75