Skip to content

V
V8
Switch branch/tag
  1. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored 
      Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.

In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.

The following changes were specifically	needed:

* Frame	has been changed to explicitly manage three areas of the
  callee frame, the fixed header, the spill slot area, and the
  callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
  a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
  to support the new stack slot indexing scheme. Crankshaft, which
  doesn't support the new slot numbering in its register allocator,
  must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
  to support saving only the optimal set of used registers, which is
  only known after register allocation is finished and spill slots
  have been allocated.

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

Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  3. 17 Aug, 2015 1 commit
  5. 11 Aug, 2015 2 commits
  7. 10 Aug, 2015 1 commit
  9. 07 Aug, 2015 2 commits
  11. 31 Jul, 2015 1 commit
  13. 30 Jul, 2015 3 commits
  15. 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
  17. 17 Jul, 2015 1 commit
  19. 13 Jul, 2015 2 commits
  21. 08 Jul, 2015 1 commit
  23. 02 Jul, 2015 1 commit
  25. 01 Jul, 2015 1 commit
  27. 30 Jun, 2015 1 commit
  29. 26 Jun, 2015 1 commit
  31. 25 Jun, 2015 2 commits
  33. 17 Jun, 2015 1 commit
  35. 05 Jun, 2015 1 commit
  37. 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
  39. 21 May, 2015 1 commit
  41. 19 May, 2015 1 commit
  43. 08 May, 2015 2 commits
  45. 05 May, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Fix tail call optimization. · d21de2a4
      bmeurer authored 
      Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

BUG=v8:4076
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#28219}
      d21de2a4
  47. 04 May, 2015 1 commit
  49. 30 Apr, 2015 2 commits
    • balazs.kilvady's avatar
      MIPS: Fix 'Detect simple tail calls'. · a384c143
      balazs.kilvady authored 
      4b122b75

BUG=

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

Cr-Commit-Position: refs/heads/master@{#28183}
      a384c143
    • 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
  51. 20 Apr, 2015 2 commits
  53. 14 Apr, 2015 1 commit
  55. 09 Apr, 2015 2 commits
    • balazs.kilvady's avatar
      MIPS: [turbofan] Materialize JSFunction from frame if possible. · 8157b6c9
      balazs.kilvady authored 
      Port 725cdc53

Original commit message:
This reduces the overhead of recursive calls when context specialization
is enabled. Based on this it might be possible to further reduce the
overhead by also specializing the call itself.

As a drive-by-fix, port the fast context materialization optimization to
arm and arm64, that was previously only supported on x64 and ia32.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#27700}
      8157b6c9
    • 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
  57. 08 Apr, 2015 2 commits