Skip to content

V
V8
Switch branch/tag
  1. 15 Apr, 2016 1 commit
    • zhengxing.li's avatar
      X87: [generators] Decouple generator resume from fullcodegen. · 0e8d220e
      zhengxing.li authored 
        port 974721c6 (r35283)

  original commit message:
  Introduce a ResumeGeneratorTrampoline, which does the actual stack state
  reconstruction (currently always restores a fullcodegen frame), and
  introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
  %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
  this native builtin.

  Also unify the flooding in case of step-in to always work based on
  JSFunction and remove the special casing for JSGeneratorObject.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35510}
      0e8d220e
  3. 14 Apr, 2016 3 commits
  5. 12 Apr, 2016 2 commits
  7. 11 Apr, 2016 1 commit
  9. 08 Apr, 2016 1 commit
  11. 07 Apr, 2016 1 commit
  13. 06 Apr, 2016 3 commits
    • jyan's avatar
      S390: [generators] Decouple generator resume from fullcodegen. · 41a92985
      jyan authored 
      Port 974721c6

Original commit message:
    Introduce a ResumeGeneratorTrampoline, which does the actual stack state
    reconstruction (currently always restores a fullcodegen frame), and
    introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
    %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
    this native builtin.

    Also unify the flooding in case of step-in to always work based on
    JSFunction and remove the special casing for JSGeneratorObject.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35316}
      41a92985
    • mbrandy's avatar
      PPC: [generators] Decouple generator resume from fullcodegen. · 1e001e71
      mbrandy authored 
      Port 974721c6

Original commit message:
    Introduce a ResumeGeneratorTrampoline, which does the actual stack state
    reconstruction (currently always restores a fullcodegen frame), and
    introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
    %GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
    this native builtin.

    Also unify the flooding in case of step-in to always work based on
    JSFunction and remove the special casing for JSGeneratorObject.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, bjaideep@ca.ibm.com
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35314}
      1e001e71
    • bmeurer's avatar
      [generators] Decouple generator resume from fullcodegen. · 974721c6
      bmeurer authored 
      Introduce a ResumeGeneratorTrampoline, which does the actual stack state
reconstruction (currently always restores a fullcodegen frame), and
introduce appropriate TurboFan builtins for %GeneratorPrototype%.next,
%GeneratorPrototype%.return and %GeneratorPrototype%.throw based on
this native builtin.

Also unify the flooding in case of step-in to always work based on
JSFunction and remove the special casing for JSGeneratorObject.

R=mstarzinger@chromium.org, neis@chromium.org
TBR=rossberg@chromium.org
BUG=chromium:513471
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35283}
      974721c6
  15. 05 Apr, 2016 2 commits
  17. 04 Apr, 2016 2 commits
    • yangguo's avatar
      [debugger] fix step-next for tail calls. · 3d4f85ab
      yangguo authored 
      R=ishell@chromium.org
BUG=v8:4698
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#35230}
      3d4f85ab
    • neis's avatar
      Preserve exception message in iterator finalization. · f70b3d3b
      neis authored 
      The parser uses a try-catch in order to record when the client of an iterator
throws.  The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.

This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
  cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
  finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
  only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
  reusing the (not-cleared) pending message

R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#35226}
      f70b3d3b
  19. 01 Apr, 2016 2 commits
  21. 31 Mar, 2016 1 commit
    • bmeurer's avatar
      [full-codegen] Reload context register after intrinsic call. · 833618d9
      bmeurer authored 
      Previously all code stubs (i.e. both platform and Crankshaft code stubs)
preserved the context register for full-codegen (neither Ignition, nor
TurboFan nor Crankshaft require this or would benefit from this), but
the newly introduced TurboFanCodeStubs no longer do this and there's no
need to, so we have to make sure in full-codegen that we restore the
context register after intrinsic calls, which potentially call
TurboFanCodeStubs.

Drive-by-fix: VisitThisFunction can be made platform independent.

R=verwaest@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#35154}
      833618d9
  23. 30 Mar, 2016 1 commit
    • Miran.Karic's avatar
      MIPS64: Replace JR/JALR with JIC/JIALC for r6. · a3f941ae
      Miran.Karic authored 
      Port of changes that replace JR and JALR instructions with JIC and JIALC
for mips64r6. Macroassembler Jump and Call functions now use JIC and
JIALC if branch delay slot is not used. Code patching is adjusted to
work with new changes. Jr and Jalr macroassembler functions are removed.
Other changes where mips32r6 uses jr/jalr are not done because mips64r6
uses j/jal instructions.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#35141}
      a3f941ae
  25. 25 Mar, 2016 1 commit
  27. 22 Mar, 2016 2 commits
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored 
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.

In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.

Also gone are any tests which relied on legacy const declarations.

Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.

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

Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
    • zhengxing.li's avatar
      X87: Extends testb and cmpb/cmpw instruction support in the ia32 assembler. · 400f6c50
      zhengxing.li authored 
        port 22523f25 (r34925)

  original commit message:
  This is in preparation for a CL that does the equivalent of http://crrev.com/1780193003 for ia32.

BUG=

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

Cr-Commit-Position: refs/heads/master@{#34974}
      400f6c50
  29. 21 Mar, 2016 1 commit
  31. 18 Mar, 2016 3 commits
  33. 17 Mar, 2016 4 commits
  35. 16 Mar, 2016 2 commits
  37. 15 Mar, 2016 2 commits
  39. 11 Mar, 2016 2 commits
  41. 10 Mar, 2016 1 commit
  43. 09 Mar, 2016 1 commit
    • mbrandy's avatar
      PPC: [runtime] Unify and simplify how frames are marked · 4445c095
      mbrandy authored 
      Port 9dcd0857

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).

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34643}
      4445c095
  45. 08 Mar, 2016 1 commit
    • verwaest's avatar
      Don't do any special normalization if a boilerplate contains function literals. · fd405704
      verwaest authored 
      This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:

function.prototype = {
  method: function() { ... }
}

Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.

This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.

BUG=chromium:593008
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34602}
      fd405704