1. 18 May, 2016 1 commit
  2. 17 May, 2016 4 commits
  3. 10 May, 2016 2 commits
  4. 09 May, 2016 2 commits
  5. 03 May, 2016 2 commits
  6. 26 Apr, 2016 1 commit
  7. 25 Apr, 2016 1 commit
  8. 22 Apr, 2016 1 commit
  9. 19 Apr, 2016 1 commit
    • adamk's avatar
      Remove all non-function-name uses of CONST_LEGACY · 59546149
      adamk authored
      Now that all 'const' declarations are of the ES2015 variety, the only
      use of CONST_LEGACY is for function name bindings in sloppy mode
      named function expressions.
      
      This patch aims to delete all code meant to handle other cases, which
      mostly had to do with hole initialization/hole checks. Since function
      name bindings are initialized at entry to a function, it's impossible
      to ever observe one in an uninitialized state.
      
      To simplify the patch further, it removes the `IMPORT` VariableMode,
      as it's not likely to be needed (IMPORT is identical to CONST for
      the purpose of VariableMode).
      
      Review URL: https://codereview.chromium.org/1895973002
      
      Cr-Commit-Position: refs/heads/master@{#35632}
      59546149
  10. 18 Apr, 2016 2 commits
  11. 15 Apr, 2016 1 commit
  12. 14 Apr, 2016 3 commits
  13. 11 Apr, 2016 1 commit
  14. 08 Apr, 2016 1 commit
  15. 07 Apr, 2016 1 commit
  16. 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
  17. 05 Apr, 2016 2 commits
  18. 04 Apr, 2016 1 commit
  19. 01 Apr, 2016 1 commit
  20. 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
  21. 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
  22. 17 Mar, 2016 2 commits
  23. 16 Mar, 2016 2 commits
  24. 08 Mar, 2016 4 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] Fix borked ARM build after r34572. · b18707b5
      mstarzinger authored
      TBR=machenbach@chromium.org
      NOTRY=true
      NOTREECHECKS=true
      
      Review URL: https://codereview.chromium.org/1777473002
      
      Cr-Commit-Position: refs/heads/master@{#34574}
      b18707b5
    • 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
  25. 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