1. 25 Feb, 2019 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Skip arguments adaptor when target cannot observe arguments. · 75629d5f
      Benedikt Meurer authored
      When calling a known function from optimized code, where the number of
      actual arguments does not match the number of expected arguments,
      TurboFan has to call indirectly via the arguments adaptor trampoline,
      which creates an argument adaptor frame underneath the activation record
      for the callee. This is done so that the callee can still get to the
      actual arguments, using either
      
      1. the arguments object, or
      2. rest parameters (to get to superfluous arguments), or
      3. the non-standard Function.arguments accessor (for sloppy mode
         functions), or
      4. direct eval(), where we don't know whether there's a use of the
         arguments object hiding somewhere in the string.
      
      However going through the arguments adaptor trampoline is quite
      expensive usually, it seems to be responsible for over 60% of the
      call overhead in those cases.
      
      So this adds a fast path for the case of calling strict mode functions
      where we have an arguments mismatch, but where we are sure that the
      callee cannot observe the actual arguments. We use a bit on the
      SharedFunctionInfo to indicate that this is safe, which is controlled
      by hints from the Parser which knows whether the callee uses either
      arguments object or rest parameters.
      
      In those cases we use a direct call from optimized code, passing the
      expected arguments instead of the actual arguments. This improves the
      benchmark on the document below by around 60-65%, which is exactly
      the overhead of the arguments adaptor trampoline that we save in this
      case.
      
      This also adds a runtime flag --fast_calls_with_arguments_mismatches,
      which can be used to turn off the new behavior. This might be handy
      for checking the performance impact via Finch.
      
      Bug: v8:8895
      Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch
      Reviewed-on: https://chromium-review.googlesource.com/c/1482735
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59825}
      75629d5f
    • Sigurd Schneider's avatar
      [cleanup] Remove ast.h include in shared-function-info-inl.h · 257433ec
      Sigurd Schneider authored
      This removes ast.h as include from about ~500 includers of the latter.
      
      Bug: v8:8834
      Change-Id: I294026d4bb29b878820d43c117b04a9645a457ae
      Reviewed-on: https://chromium-review.googlesource.com/c/1485835Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59822}
      257433ec
  2. 20 Feb, 2019 1 commit
  3. 15 Feb, 2019 1 commit
  4. 14 Feb, 2019 1 commit
  5. 13 Feb, 2019 1 commit
    • Toon Verwaest's avatar
      [ast] Always visit all AST nodes, even dead nodes · 9439a1d2
      Toon Verwaest authored
      We'll let the bytecode compiler and optimizing compilers deal with dead code,
      rather than the ast visitors. The problem is that the visitors previously
      disagreed upon what was dead. That's bad if necessary visitors omit parts of
      the code that the bytecode generator will actually visit.
      
      I did consider removing the AST nodes immediately in the parser, but that
      adds overhead and actually broke code coverage. Since dead code shouldn't be
      shipped to the browser anyway (and we can still omit it later in the bytecode
      generator), I opted for keeping the nodes instead.
      
      Change-Id: Ib02fa9031b17556d2e1d46af6648356486f8433d
      Reviewed-on: https://chromium-review.googlesource.com/c/1470108
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59569}
      9439a1d2
  6. 06 Feb, 2019 2 commits
    • Toon Verwaest's avatar
      [parser] Customize preparsed scope variable resolution · c1119e21
      Toon Verwaest authored
      Otherwise preparsed variables will cause unnecessary dynamic variable
      allocation, which is especially bad when we're preparsing top-level functions
      with references to other global variables.
      
      Change-Id: I2fa17dae8c1cc5264a26ddc8b8868de1d791b0ac
      Reviewed-on: https://chromium-review.googlesource.com/c/1456040
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59420}
      c1119e21
    • Toon Verwaest's avatar
      [parser] Handle 'this' with a special ThisExpression rather than VariableProxy · 3f2b5017
      Toon Verwaest authored
      "this" is a very common expression. By using a single ThisExpression object
      we can both avoid allocating many unnecessary VariableProxies and specialize
      the resolution of this since we know where it's declared up-front. This also
      avoids having to special-case "this" reference handling in the paths that would
      behave differently for "this" than for regular references; e.g., with-scopes.
      
      The tricky pieces are due to DebugEvaluate and this/super() used as default
      parameters of arrow functions. In the former case we replace the WITH_SCOPE
      with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still
      rely on regular dynamic variable lookup. Arrow functions are dealt with by
      marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression
      ends up being an arrow function, we force context allocate on the outer scope
      (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the
      arrow function can expose "this").
      
      The CL also removes the now unused ThisFunction AST node.
      
      Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef
      Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59393}
      3f2b5017
  7. 31 Jan, 2019 1 commit
  8. 28 Jan, 2019 4 commits
  9. 25 Jan, 2019 3 commits
  10. 24 Jan, 2019 1 commit
  11. 23 Jan, 2019 2 commits
  12. 22 Jan, 2019 2 commits
  13. 21 Jan, 2019 3 commits
  14. 18 Jan, 2019 1 commit
  15. 16 Jan, 2019 3 commits
  16. 15 Jan, 2019 2 commits
    • Toon Verwaest's avatar
      [parser] Clear parenthesized flag on collapsing nary expressions · 5f8a3e1e
      Toon Verwaest authored
      The parenthesized flag guarantees that the contents was validated as a possible
      arrow head. By collapsing a parenthesized expression with an outer binary
      expression we invalidly kept the flag and invalidly assumed that the collapsed
      expression was validated.
      
      Bug: chromium:921382
      Change-Id: I207dcbfd228a1ed216130226fdb7ea045b89b85a
      Reviewed-on: https://chromium-review.googlesource.com/c/1412172
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58829}
      5f8a3e1e
    • Toon Verwaest's avatar
      [parser] Give hoisting sloppy block functions a valid position · 8436715f
      Toon Verwaest authored
      A sloppy function in a block scope implicitily creates a var in the outer
      declaration scope if it's not blocked. The assignment created reads the local
      lexical declaration for the function. The reference introduced automatically
      takes part in NeedsHoleCheck, requiring the reference to have a valid position.
      Since the assignment will happen after the local declaration, we give the
      end_position() of the closure as the position of the reference, so hole checks
      can be omitted.
      
      Bug: chromium:917755
      Change-Id: Iee0e042b2463f97f05075f9eec09dac8c6eaf539
      Reviewed-on: https://chromium-review.googlesource.com/c/1408991Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58823}
      8436715f
  17. 14 Jan, 2019 1 commit
  18. 10 Jan, 2019 1 commit
  19. 09 Jan, 2019 4 commits
  20. 08 Jan, 2019 1 commit
    • Toon Verwaest's avatar
      [parser] Disambiguate variables through expression-scope · f9529f6b
      Toon Verwaest authored
      Previously we'd always push variable proxies into the unresolved list of the
      current scope, and possibly delete them from the list later in case they end up
      being declarations. If variables become assigned, there were two ways to mark
      them as such: The preparser would marked the variables tracked on the
      PreParserExpression, and the parser would traverse the LHS AST to find and mark
      all variables.
      
      After this CL, if the scope already knows it's tracking declarations, the
      variables are never added to the unresolved list in the first place. If the
      scope is ambigous, it tracks the variable proxies on the side and only adds
      them to the unresolved list if they end up being references rather than
      declarations. The same list is now used to bulk mark all LHS variables as
      assigned; uniformely for both the parser and the preparser.
      
      In a next step we'll also use the scope to create declarations. That way we can
      stop tracking variables_ on PreParserExpression altogether.
      
      Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f
      Reviewed-on: https://chromium-review.googlesource.com/c/1397669
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58629}
      f9529f6b
  21. 07 Jan, 2019 3 commits