Skip to content

V
V8
Switch branch/tag
  1. 29 Jun, 2016 1 commit
  3. 27 Jun, 2016 1 commit
  5. 10 Mar, 2016 2 commits
    • zhengxing.li's avatar
      X87: [turbofan] [deoptimizer] Support inlining of ES6 tail calls. · 7b84d299
      zhengxing.li authored 
        port c29a4560(r34610)

  original commit message:
  In case when F was called with incompatible number of arguments (and therefore
  the arguments adator frame was created), F inlines a tail call of G which then
  deopts the deoptimizer should also remove the arguments adaptor frame for F.

  This CL adds required machinery to the deoptimizer.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34651}
      7b84d299
    • zhengxing.li's avatar
      X87: [runtime] Unify and simplify how frames are marked. · 7a51f8c8
      zhengxing.li authored 
        port 9dcd0857 (r34571)

  original commit message:
  Before this CL, various code stubs used different techniques
  for marking their frames to enable stack-crawling and other
  access to data in the frame. All of them were based on a abuse
  of the "standard" frame representation, e.g. storing the a
  context pointer immediately below the frame's fp, and a
  function pointer after that. Although functional, this approach
  tends to make stubs and builtins do an awkward, unnecessary
  dance to appear like standard frames, even if they have
  nothing to do with JavaScript execution.

  This CL attempts to improve this by:

  * Ensuring that there are only two fundamentally different
    types of frames, a "standard" frame and a "typed" frame.
    Standard frames, as before, contain both a context and
    function pointer. Typed frames contain only a minimum
    of a smi marker in the position immediately below the fp
    where the context is in standard frames.
  * Only interpreted, full codegen, and optimized Crankshaft and
    TurboFan JavaScript frames use the "standard" format. All
    other frames use the type frame format with an explicit
    marker.
  * Typed frames can contain one or more values below the
    type marker. There is new magic macro machinery in
    frames.h that simplifies defining the offsets of these fields
    in typed frames.
  * A new flag in the CallDescriptor enables specifying whether
    a frame is a standard frame or a typed frame. Secondary
    register location spilling is now only enabled for standard
    frames.
  * A zillion places in the code have been updated to deal with
    the fact that most code stubs and internal frames use the
    typed frame format. This includes changes in the
    deoptimizer, debugger, and liveedit.
  * StandardFrameConstants::kMarkerOffset is deprecated,
    (CommonFrameConstants::kContextOrFrameTypeOffset
    and StandardFrameConstants::kFrameOffset are now used
    in its stead).

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34648}
      7a51f8c8
  7. 03 Mar, 2016 1 commit
  9. 29 Feb, 2016 1 commit
  11. 15 Feb, 2016 1 commit
  13. 11 Feb, 2016 1 commit
  15. 12 Jan, 2016 1 commit
  17. 27 Nov, 2015 2 commits
  19. 23 Oct, 2015 1 commit
    • zhengxing.li's avatar
      X87: Re-reland: Remove register index/code indirection. · 2e5845f1
      zhengxing.li authored 
          port 5cf1c0bc (r31087).

    original commit message:
    Previous to this patch, both the lithium and TurboFan register
    allocators tracked allocated registers by "indices", rather than
    the register codes used elsewhere in the runtime. This patch
    ensures that codes are used everywhere, and in the process cleans
    up a bunch of redundant code and adds more structure to how the
    set of allocatable registers is defined.

    Some highlights of changes:

    * TurboFan's RegisterConfiguration class moved to V8's top level
      so that it can be shared with Crankshaft.
    * Various "ToAllocationIndex" and related methods removed.
    * Code that can be easily shared between Register classes on
      different platforms is now shared.
    * The list of allocatable registers on each platform is declared
      as a list rather than implicitly via the register index <->
      code mapping.

    additional comment:
    This patch must be work with CL https://codereview.chromium.org/1405673003/
    and CL https://codereview.chromium.org/1413343002/
    which provide the needed register allocation common code change in
    v8 for this CL

BUG=

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

Cr-Commit-Position: refs/heads/master@{#31494}
      2e5845f1
  21. 17 Aug, 2015 1 commit
  23. 12 Aug, 2015 1 commit
  25. 24 Jul, 2015 1 commit
  27. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  29. 03 Jun, 2015 1 commit
  31. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored 
      Embed constant pools within their corresponding Code
objects.

This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.

Currently supported on PPC and ARM.  Enabled by default on
PPC only.

This yields a 6% improvment in Octane on PPC64.

R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y

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

Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  33. 01 Jun, 2015 1 commit
  35. 18 Mar, 2015 1 commit
  37. 11 Feb, 2015 2 commits
  39. 05 Dec, 2014 1 commit
  41. 20 Sep, 2014 1 commit
  43. 12 Sep, 2014 1 commit
  45. 04 Aug, 2014 1 commit
  47. 30 Jul, 2014 1 commit
  49. 26 Jun, 2014 1 commit
    • weiliang.lin@intel.com's avatar
      X87: The IC exposes a register definition. · 8ff53a8d
      weiliang.lin@intel.com authored 
      port r22011

original commit message:
  Centralize a register definition in an IC that provides:
  1) symbolic names for the register (like, edx == receiver)
  2) defines ordering when passed on the stack

  Code that implements or uses the IC should use this definition instead of "knowing" what the registers are. Or at least have the definition to validate it's assumptions.

  As a side effect of avoiding runtime static initializers (enforced by tools/check-static-initializers.sh, neat), I gave ownership of the registers array to CodeStubInterfaceDescriptor. This prompted a cleanup of that struct

BUG=
R=weiliang.lin@intel.com

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

Patch from Chunyang Dai <chunyang.dai@intel.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22028 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      8ff53a8d
  51. 03 Jun, 2014 1 commit
  53. 27 May, 2014 1 commit
  55. 26 May, 2014 2 commits
  57. 23 May, 2014 1 commit
  59. 13 May, 2014 1 commit
  61. 09 May, 2014 1 commit
  63. 29 Apr, 2014 1 commit
  65. 14 Mar, 2014 1 commit
  67. 03 Mar, 2014 1 commit
  69. 28 Feb, 2014 1 commit
  71. 22 Nov, 2013 1 commit