1. 25 Oct, 2017 1 commit
  2. 19 Oct, 2017 1 commit
  3. 13 Oct, 2017 1 commit
  4. 11 Oct, 2017 1 commit
  5. 10 Oct, 2017 1 commit
  6. 09 Oct, 2017 3 commits
  7. 05 Oct, 2017 3 commits
  8. 26 Sep, 2017 1 commit
  9. 15 Sep, 2017 1 commit
  10. 08 Sep, 2017 1 commit
  11. 07 Sep, 2017 1 commit
  12. 25 Aug, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Always write the deferred command result register · e5df5bd0
      Leszek Swirski authored
      For deferred commands (such as in try-finally), some deferred commands
      save and restore the accumulator using a result register (e.g. return,
      throw, rethrow), while others don't (e.g. break, continue,
      fall-through).
      
      However, conditionally reading this result register that may not ever be
      written caused it to be considered live from the start of the function,
      as far as the liveness analysis could statically tell.
      
      Now, we write the result register for all deferred commands, including
      the fall-through. As a micro-optimization, we re-use the Smi command
      tokeen to clobber the result, rather than emitting an LdaUndefined.
      
      Bug: chromium:758472
      Change-Id: I2ea65e2249b40ee6403216e654a8bb88d50bec3b
      Reviewed-on: https://chromium-review.googlesource.com/635592
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47612}
      e5df5bd0
  13. 11 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      [Interpreter] Remove new.target from fixed frame slot. · c820b89b
      Ross McIlroy authored
      Removes the new.target slot from the interpreter's fixed frame. Instead
      adds a field to BytecodeArray to get the bytecode's incoming
      new.target or generator object register. The InterpreterEntryTrampoline
      then sets this register with the incoming new.target (or generator object)
      when the function is called. This register can be directly the new.target
      or generator object variable if they are LOCAL location, otherwise it is a
      temporary register which is then moved to the variable's location during the
      function prologue.
      
      This fixes a hack in the deoptimizer where we would set the new.target fixed
      slot to undefined in order to avoid extending it's lifetime through the
      optimized code - now it's just a standard register and can be optimized away
      as normal.
      
      Bug=v8:6644
      
      Change-Id: Ieb8cc34cccefd9fb6634a90cbc77c6002a54f2ae
      Reviewed-on: https://chromium-review.googlesource.com/608966
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47320}
      c820b89b
    • Ross McIlroy's avatar
      [fullcodegen] Delete FullCodegen. · 1458e8b0
      Ross McIlroy authored
      Deletes the now unused Full-codegen compiler. Also removes some macro
      assembler instructions which are no longer used.
      
      Note: there is still additional cleanup work to do after this lands
      (e.g., remove support for FCG frames support and FCG
      debugger support, etc.), but this will be done in followup CLs to keep
      this patch managable.
      
      BUG=v8:6409
      
      Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
      Reviewed-on: https://chromium-review.googlesource.com/584773
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47307}
      1458e8b0
  14. 09 Aug, 2017 1 commit
  15. 02 Aug, 2017 1 commit
  16. 01 Aug, 2017 2 commits
    • Caitlin Potter's avatar
      Reland "[async-iteration] implement spec-change to `yield` in async generators" · ac6ed35a
      Caitlin Potter authored
      Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
      
      AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
      unwrapped before the builtin call via Await, allowing Promise rejections to
      affect the generator control flow.
      
      Thus, all `yield <expr>` implicitly become `yield await <expr>`.
      
      Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
      generator is resumed with `.return()`, the parameter passed to .return() is
      awaited before generator execution properly continues).
      
      BUG=v8:6187, v8:5855
      R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
      TBR=rmcilroy@chromium.org, neis@chromium.org
      
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
      Reviewed-on: https://chromium-review.googlesource.com/594500Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#47058}
      ac6ed35a
    • Sathya Gunasekaran's avatar
      [parser] Provide better error when destructuring callable · c805d5e3
      Sathya Gunasekaran authored
      The patch changes CallPrinter's AST traversal to continue even after
      the first positive match for an AST node. This helps us check for the
      subsequent GetIterator AST node in case of destructuring.
      
      We can not differentiate between the function call failing and the
      GetIterator failing based on source position info. This would involve
      runtime checks costing performance.
      
      Instead of providing an incorrect error, we provide both the
      possiblities to user and allow them to disambiguate.
      
      Previously,
        d8> function f() { return 5; }
        undefined
        d8> var [a] = f();
        (d8):1: TypeError: f is not a function
        var [a] = f();
                  ^
        TypeError: f is not a function
            at (d8):1:11
      
      
      Now,
        d8> function f() { return 5; }
        undefined
        d8> var [a] = f();
        (d8):1: TypeError: f is not a function or its return value is not iterable
        var [a] = f();
                  ^
        TypeError: f is not a function or its return value is not iterable
            at (d8):1:11
      
      Bug: v8:6616, v8:6513
      Change-Id: I3d6427f10cae54951b0ad0e5ddcbe802bb7191c1
      Reviewed-on: https://chromium-review.googlesource.com/594894
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47025}
      c805d5e3
  17. 31 Jul, 2017 2 commits
  18. 27 Jul, 2017 1 commit
  19. 25 Jul, 2017 4 commits
  20. 21 Jul, 2017 1 commit
  21. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored
      This reverts commit a2fcdc7c.
      
      Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
      
      Original change's description:
      > [runtime] Move profiler ticks from SFI to feedback vector
      > 
      > Instead of counting profiler ticks on the shared function info (which is
      > shared between native contexts), count them on the feedback vector
      > (which is not). This allows us to continue pushing optimization
      > decisions off the SFI, onto the feedback vector.
      > 
      > Note that a side-effect of this is that ICs don't have to walk the stack
      > to reset profiler ticks, as they can access the feedback vector directly
      > from their feedback nexus.
      > 
      > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
      > Reviewed-on: https://chromium-review.googlesource.com/544888
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46411}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
      Reviewed-on: https://chromium-review.googlesource.com/574227
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  22. 14 Jul, 2017 2 commits
    • Caitlin Potter's avatar
      [generators] remove SuspendFlags enum and related code · 53553f5d
      Caitlin Potter authored
      SuspendFlags was originally used by the suspend operation to determine
      which field to record the bytecode offset of a suspended generator, and
      the value the generator was resumed with. For async generators, await
      operations would use a separate field, in order to preserve the previous
      yield input value. This was important to ensure `function.sent`
      continued to function correctly.
      
      As function.sent is being retired, this allows the removal of support
      for that. Given that this was the only real need for SuspendFlags in the
      first place (with other uses tacked on as a hack), this involves several
      other changes as well:
      
      - Modification of MacroAssembler AssertGeneratorObject. No longer
        accepts a SuspendFlags parameter to determine which type of check to
        perform.
      - Removal of `flags` operand from SuspendGenerator bytecode, and the
        GeneratorStore js-operator.
      - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
      - Removal of Runtime functions, interpreter intrinsics and
        AccessBuilders associated with the [[await_input_or_debug_pos]] field
        in JSAsyncGeneratorObject, as this field no longer exists.
      - Addition of a new `Yield` AST node (subclass of Suspend) in order to
        prevent the need for the other SuspendFlag values.
      
      BUG=v8:5855
      TBR=bmeurer@chromium.org
      
      Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
      Reviewed-on: https://chromium-review.googlesource.com/570485
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46683}
      53553f5d
    • Caitlin Potter's avatar
      [async-await] desugar Await in BytecodeGenerator · 8b5b444a
      Caitlin Potter authored
      This includes several changes. From most to least interesting:
      
      - No longer implement AwaitExpressions using a do-expression.
      - Reduces frame-size of async generators by not allocating temporary
        variables to hold results of Await epxressions.
      - Streamline and reduce generated bytecodes for Await.
      - Debugger no longer emits a debug::kCallBreakLocation breakpoint for
      the JS-builtin call performed for Await, and instead only emits such
      a breakpoint if the operand of Await is actually a call.
      - Push fewer parameters to Await* builtins, using the receiver for the
        first parameter (possible now that the CallRuntime invocation not
        part of the AST).
      - Adds a new Await AST node. No new members or anything, but it seemed
        palatable to avoid having `if (is_await())` in a number of
        VisitSuspend functions.
      
      BUG=v8:5855, v8:5099, v8:4483
      R=rmcilroy@chromium.org, kozyatinskiy@chromium.org, yangguo@chromium.org
      TBR=bmeurer@chromium.org
      
      Change-Id: I9cd3fda99cd40295c04fdf1aea01b5d83fac6caf
      Reviewed-on: https://chromium-review.googlesource.com/558806
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46666}
      8b5b444a
  23. 10 Jul, 2017 1 commit
  24. 06 Jul, 2017 1 commit
  25. 05 Jul, 2017 1 commit
  26. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored
      For interpreted functions, use the optimized code slot in the feedback
      vector to store an optimization marker (optimize/in optimization queue)
      rather than changing the JSFunction's code object. Then, adapt the
      self-healing mechanism to also dispatch based on this optimization
      marker. Similarly, replace SFI marking with optimization marker checks
      in CompileLazy.
      
      This allows JSFunctions to share optimization information (replacing
      shared function marking) without leaking this information across native
      contexts. Non I+TF functions (asm.js or --no-turbo) use a
      CheckOptimizationMarker shim which generalises the old
      CompileOptimized/InOptimizationQueue builtins and also checks the same
      optimization marker as CompileLazy and InterpreterEntryTrampoline.
      
      This is a reland of https://chromium-review.googlesource.com/c/509716
      
      Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
      Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  27. 15 Jun, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [parser] Better error message when destructuring against undefined/null · bc2c785c
      Sathya Gunasekaran authored
      Previously, when destructuring against null or undefined we would
      print:
      
        d8> var { x } = null
        (d8):1: TypeError: Cannot match against 'undefined' or 'null'.
        var { x } = null
        ^
        TypeError: Cannot match against 'undefined' or 'null'.
            at (d8):1:1
      
      
      The above message uses the term "match" which isn't a common term in
      JavaScript to describe destructuring. This message also doesn't
      provide the name of the property that fails destructuring.
      
      This patch changes the error message to be:
      
        d8> var { x } = null;
        (d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
        var { x } = null;
              ^
        TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
            at (d8):1:1
      
      This patch changes the message to say "destructure" instead of "match".
      
      This patch adds support for printing property names that are string
      literals. We iterate through every property and pick the first string
      literal property name if it exists. This provides at least some
      feedback to the developer.
      
      This patch also makes the pointer point to the position of the
      property name that fails destructuring.
      
      For computed and numeric property names, we print a generic error:
        d8> var { 1: x } = null
        (d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
        var { 1: x } = null
        ^
        TypeError: Cannot destructure against 'undefined' or 'null'.
            at (d8):1:1
      
      Bug: v8:6499
      Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
      Reviewed-on: https://chromium-review.googlesource.com/537341Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45965}
      bc2c785c
  28. 13 Jun, 2017 2 commits