Skip to content

V
V8
Switch branch/tag
  1. 18 Apr, 2016 2 commits
  3. 15 Apr, 2016 1 commit
  5. 14 Apr, 2016 3 commits
  7. 11 Apr, 2016 1 commit
  9. 08 Apr, 2016 1 commit
  11. 07 Apr, 2016 1 commit
  13. 06 Apr, 2016 1 commit
    • 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 1 commit
  19. 01 Apr, 2016 1 commit
  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. 25 Mar, 2016 1 commit
  25. 22 Mar, 2016 1 commit
    • 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
  27. 17 Mar, 2016 2 commits
  29. 16 Mar, 2016 2 commits
  31. 08 Mar, 2016 3 commits
    • 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
    • mstarzinger's avatar
      [compiler] Remove support for concurrent OSR. · 26692242
      mstarzinger authored 
      R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34572}
      26692242
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored 
      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).

LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  33. 06 Mar, 2016 1 commit
    • neis's avatar
      Get rid of the different kinds of yield in the AST & full-codegen. · f24dffea
      neis authored 
      Now there is just one kind, corresponding to what was called "initial" before.
Replacement for "suspend": when the parser sees a yield in JS code, it
will turn it into a Yield node but wrap its argument in an iterator result
object.  Replacement for "final": the parser simply inserts a return statement
instead.

R=littledan@chromium.org, mstarzinger@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#34515}
      f24dffea
  35. 04 Mar, 2016 1 commit
  37. 03 Mar, 2016 1 commit
    • bmeurer's avatar
      [runtime] Rename IsUndetectableObject to IsUndetectable. · 0b3e436a
      bmeurer authored 
      This is more consistent with the current naming scheme (i.e. IsCallable
for callable bit on map, IsConstructor for constructor bit on map, and
now IsUndetectable for undetectable bit on map).

Also simplify the fallthrough case for Object::Equals, because we don't
need to check for Null or Undefined or Undetectable, as both Null and
Undefined already have the undetectable bit set on their maps.

R=machenbach@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34458}
      0b3e436a
  39. 02 Mar, 2016 1 commit
    • yangguo's avatar
      [debugger] Ensure at least one breakable position per function. · 44e9622a
      yangguo authored 
      The function literal consists of a list of statements. Each statement
is associated with a statement position including break location. The
only exception to this rule is when the function immediately throws if
scope resolution found an illegal redeclaration. Make sure that we add a
break location for this case as well. The debugger relies on this.

R=bmeurer@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#34422}
      44e9622a
  41. 01 Mar, 2016 1 commit
  43. 29 Feb, 2016 1 commit
    • bmeurer's avatar
      [stubs] Introduce a proper ToBooleanStub. · d1df58e8
      bmeurer authored 
      Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34361}
      d1df58e8
  45. 27 Feb, 2016 1 commit
  47. 26 Feb, 2016 1 commit
  49. 25 Feb, 2016 1 commit
  51. 24 Feb, 2016 4 commits
  53. 23 Feb, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Implement operand stack depth tracking. · 38915ed7
      mstarzinger authored 
      This implements a mechanism to track the exact depth of the operand
stack in full-codegen for every sub-expression visitation. So far we
only tracked the depth at statement level, but not at expression level.
With the introduction of do-expressions it will be possible to construct
local control flow (i.e. break, continue and friends) that target labels
at an arbitrary operand stack depth, making this tracking a prerequisite
for full do-expression support.

R=rossberg@chromium.org,jarin@chromium.org
BUG=v8:4755,v8:4488
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#34211}
      38915ed7
  55. 22 Feb, 2016 1 commit
    • mstarzinger's avatar
      [fullcodegen] Lift restriction on --debug-code flag. · 0427abf3
      mstarzinger authored 
      This removes a restriction from full-codegen that limited the usability
of the --debug-code flag to only no-snap configurations. The reasoning
for the restriction would still hold, if we ever put full-codegen code
into the snapshot, which we don't. Also there already are several places
in full-codegen that queried the FLAG_debug_code directly, a more
reliable mechanism will be needed if we snapshot full code.

R=yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#34189}
      0427abf3
  57. 19 Feb, 2016 1 commit