1. 15 Nov, 2017 1 commit
  2. 09 Nov, 2017 1 commit
    • Mostyn Bramley-Moore's avatar
      [jumbo] fix B macro/symbol clashes in arm64 builds · b9c99322
      Mostyn Bramley-Moore authored
      assembler-arm64.h and assembler-arm64-inl.h have a B() function
      which conflicts with the B macro in bytecode-utils.h.
      
      Headers that leak macros can be annoying to deal with, in this case
      we can't simply undef B at the end of source files that include
      bytecode-utils.h because the second source file that includes
      bytecode-utils.h won't see the B macro.  Let's just move this macro
      into the two unittest files that include this header.
      
      Bug: chromium:746958
      Change-Id: I588b73fe81615f882a0e010c92ba187d3bc2bf25
      Reviewed-on: https://chromium-review.googlesource.com/758779
      Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49258}
      b9c99322
  3. 27 Oct, 2017 1 commit
    • Adam Klein's avatar
      [ast] Move AstValue implementation into Literal · 317cf321
      Adam Klein authored
      This eliminates the AstValue class, effectively moving its
      implementation into the Literal AstNode. This should cause
      no difference in behavior, but it does signal some shifts
      in the underlying system. Biggest changes include:
      
        - Reduction in AST memory usage
        - No duplicate HeapNumbers in Ignition constant pools
        - Non-String values are allocated either at constant pool
          creation time (or at boilerplate creation time for literals),
          rather than at AstValueFactory::Internalize() time.
      
      There are a variety of test-only/debug-only changes due to these
      switches as well.
      
      Bug: v8:6984
      Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
      Reviewed-on: https://chromium-review.googlesource.com/731111
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49013}
      317cf321
  4. 24 Oct, 2017 1 commit
  5. 23 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce InstanceOfIC to collect rhs feedback. · bcee1406
      Benedikt Meurer authored
      This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
      constant feedback about the right-hand side of instanceof operators,
      including both JSFunction and JSBoundFunction instances. TurboFan then
      uses the feedback to optimize instanceof in places where the right-hand
      side is not a known constant (known to TurboFan).
      
      This addresses the odd performance cliff that we see with instanceof in
      functions with multiple closures. It was discovered as one of the main
      bottlenecks on the uglify-es test in the web-tooling-benchmark. The
      uglify-es test (run in separation) is ~18% faster with this change.
      
      On the micro-benchmark in the tracking bug we go from
      
        instanceofSingleClosure_Const: 69 ms.
        instanceofSingleClosure_Class: 246 ms.
        instanceofMultiClosure: 246 ms.
        instanceofParameter: 246 ms.
      
      to
      
        instanceofSingleClosure_Const: 70 ms.
        instanceofSingleClosure_Class: 75 ms.
        instanceofMultiClosure: 76 ms.
        instanceofParameter: 73 ms.
      
      boosting performance by roughly 3.6x and thus effectively removing the
      performance cliff around instanceof.
      
      Bug: v8:6936, v8:6971
      Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
      Reviewed-on: https://chromium-review.googlesource.com/730686
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48820}
      bcee1406
  6. 19 Oct, 2017 2 commits
  7. 18 Oct, 2017 1 commit
  8. 16 Oct, 2017 1 commit
  9. 11 Oct, 2017 1 commit
  10. 29 Sep, 2017 1 commit
  11. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  12. 12 Sep, 2017 3 commits
  13. 08 Sep, 2017 2 commits
  14. 05 Sep, 2017 1 commit
  15. 04 Sep, 2017 1 commit
  16. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  17. 28 Aug, 2017 1 commit
  18. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  19. 21 Aug, 2017 1 commit
  20. 25 Jul, 2017 2 commits
  21. 24 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add IC support for Call/ConstructWithSpread. · 5ee1b7ad
      Benedikt Meurer authored
      Properly hook up the (existing) IC slots for the CallWithSpread and
      ConstructWithSpread bytecodes, and change the interpreter to collect
      feedback (call counts and regular target function feedback) for those.
      There's no integration with the Array constructor yet, since that
      requires some yak shaving to thread through the AllocationSite to the
      Array constructor stub. Once we have a solution for that, we can also
      remove the current code duplication in the Call/Construct IC logic.
      
      Also properly hook up the newly available feedback in TurboFan. This
      will fix not only the missing target feedback, but more importantly
      the tear-up decisions for optimization are correct now in the presence
      of spread calls, and even more importantly the inlining heurstic has
      proper call frequencies for those.
      
      Some follow-up changes will be necessary to make sure we use the
      feedback even for corner cases that aren't handled properly yet. Also
      we should consider collecting feedback about the map of the spread
      at some point to be able to always inline the spread calls.
      
      Bug: v8:6399, v8:6527, v8:6630
      Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00
      Reviewed-on: https://chromium-review.googlesource.com/582647Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46832}
      5ee1b7ad
  22. 20 Jul, 2017 1 commit
    • Adam Klein's avatar
      Revert "[literals] Introduce CreateEmptyArrayLiteral Bytecode" · 62f83377
      Adam Klein authored
      This reverts commit 4851745f.
      
      Reason for revert: Top crasher on Canary, see https://crbug.com/746935
      
      Original change's description:
      > [literals] Introduce CreateEmptyArrayLiteral Bytecode
      > 
      > Empty Array literals are amongst the most commonly used literal types on our
      > top25 page list. Using a custom bytecode we can drop the boilerplate for empty
      > Array literals alltogether. However, we still need a proper AllocationSite to
      > track ElementsKind transitions.
      > 
      > Bug: v8:6211
      > Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
      > Reviewed-on: https://chromium-review.googlesource.com/567079
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46752}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com
      Bug: v8:6211, chromium:746935
      
      Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56
      Reviewed-on: https://chromium-review.googlesource.com/580193
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46804}
      62f83377
  23. 19 Jul, 2017 2 commits
  24. 18 Jul, 2017 1 commit
  25. 14 Jul, 2017 1 commit
    • 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
  26. 13 Jul, 2017 1 commit
  27. 27 Jun, 2017 1 commit
  28. 23 Jun, 2017 1 commit
  29. 22 Jun, 2017 1 commit
    • Daniel Ehrenberg's avatar
      [scopes] Fix sloppy-mode block-scoped function hoisting edge case · d54ffadf
      Daniel Ehrenberg authored
      In edge cases such as the following, sloppy-mode block-scoped function
      hoisting is expected to occur:
      
        eval(`
          with({a: 1}) {
            function a() {}
          }
        `)
      
      In this case, there should be the equivalent of a var declaration
      outside of the eval, which gets set to the value of the local function
      a when the body of the with is executed.
      
      Previously, the way that var declarations are hoisted out of eval
      meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
      assignment. However, such a lookup mode meant that the object in the
      with scope received the assignment!
      
      This patch fixes that error by marking the assignments produced by
      the sloppy mode block scoped function hoisting desugaring so as to
      generate a different runtime call which skips with scopes.
      
      Bug: chromium:720247, v8:5135
      Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
      Reviewed-on: https://chromium-review.googlesource.com/529230
      Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46116}
      d54ffadf
  30. 06 Jun, 2017 2 commits
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored
      This CL implements general infrastructure for block coverage together with
      initial support for if-statements.
      
      Coverage output can be generated in lcov format by d8 as follows:
      
      $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
      $ genhtml ~/simple-if.lcov -o ~/simple-if
      $ chrome ~/simple-if/index.html
      
      A high level overview of the implementation follows:
      
      The parser now collects source ranges unconditionally for relevant AST nodes.
      Memory overhead is very low and this seemed like the cleanest and simplest
      alternative.
      
      Bytecode generation uses these ranges to allocate coverage slots and insert
      IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
      for if-statements). The slot-range mapping is generated here and passed on
      through CompilationInfo, and is later accessible through the
      SharedFunctionInfo.
      
      The IncBlockCounter bytecode fetches the slot-range mapping (called
      CoverageInfo) from the shared function info and simply increments the counter.
      We don't collect native-context-specific counts as they are irrelevant to our
      use-cases.
      
      Coverage information is finally generated on-demand through Coverage::Collect.
      The only current consumer is a d8 front-end with lcov-style output, but the
      short-term goal is to expose this through the inspector protocol.
      
      BUG=v8:6000
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2882973002
      Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
    • Mythri's avatar
      [Interpreter] Introduce bytecodes that check for hole and throw. · c360c6a1
      Mythri authored
      Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole 
      / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
      In the bytecode-graph builder they are handled by introducing a deopt point
      instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
      bytecodes are removed since they are no longer required.
      
      
      Bug: v8:4280, v8:6383
      Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
      Reviewed-on: https://chromium-review.googlesource.com/509613
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45720}
      c360c6a1
  31. 02 Jun, 2017 1 commit
    • jarin's avatar
      This is a first step towards reducing the number of stores/loads when... · f0645612
      jarin authored
      This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.
      
      Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
      
      Changes:
      
      - SuspendGenerator bytecode now takes register list to save.
      - ResumeGenerator was split into two bytecodes:
        * Resume generator reads the state out and marks the generator as
            'executing'.
        * RestoreGeneratorRegisters reloads the registers from
            the generator.
          + this required adding support for output register list.
      
      - Introduced generator_object_ register in the bytecode generator.
        * in subsequent CLs, I will make better use of it, the goal is
            to get rid if the .generator_object local variable.
      
      - Taught register optimizer to flush unassigned registers.
      
      BUG=v8:6379
      
      Review-Url: https://codereview.chromium.org/2894293003
      Cr-Commit-Position: refs/heads/master@{#45675}
      f0645612
  32. 24 May, 2017 1 commit
  33. 22 May, 2017 1 commit