1. 14 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] re-implement template strings" · b8229612
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      [esnext] fix OOB read in ASTPrinter::VisistTemplateLiteral
      
      Fixes an error where TemplateLiteral printing in --print-ast
      would try to read an element beyond the length of a vector.
      
      BUG=v8:7415, chromium:820596
      R=adamk@chromium.org, gsathya@chromum.org, rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: Ie56894f73a6445550a5f95f42160c4e29ab1da42
      Reviewed-on: https://chromium-review.googlesource.com/958408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51933}
      b8229612
  2. 13 Mar, 2018 1 commit
  3. 10 Mar, 2018 3 commits
  4. 09 Mar, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] re-implement template strings · 8ae19e08
      Caitlin Potter authored
      - Add a new bytecode for the ToString operation, replacing the old
      intrinsic call (currently does not collect type feedback).
      - Add a new AST node to represent TemplateLiterals, and avoid
      generating unnecessary ToString operations in some simple cases.
      - Use a single feedback slot for each string addition, because the
      type feedback should always be the same for each addition
      
      This seems to produce a very slight improvement on JSTests benchmarks
      and bench-ruben.js from v8:7415, and it's possible that type feedback
      for the ToString bytecode could provide more opportunities to eliminate
      the runtime call in TurboFan.
      
      Doesn't touch tagged templates
      
      BUG=v8:7415
      R=rmcilroy@chromium.org, ishell@chromium.org, bmeurer@chromium.org
      
      Change-Id: If5a8c68558431f058db894d65776324abf54218e
      Reviewed-on: https://chromium-review.googlesource.com/945408Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#51853}
      8ae19e08
  5. 05 Mar, 2018 1 commit
  6. 20 Feb, 2018 1 commit
  7. 15 Feb, 2018 1 commit
  8. 13 Feb, 2018 1 commit
  9. 12 Feb, 2018 1 commit
    • Caitlin Potter's avatar
      [esnext] implement spec change to TaggedTemplate callsite caching · d3ca0d00
      Caitlin Potter authored
      Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
      which has been ratified and pulled into the specification. In particular,
      template callsite objects are no longer kept in a global, eternal Map, but
      are instead associated with their callsite, which can be collected. This
      prevents a memory leak incurred by TaggedTemplate calls.
      
      Changes, summarized:
      
          - Remove the TemplateMap and TemplateMapShape objects, instead caching
            template objects in the feedback vector.
          - Remove the `hash` member of TemplateObjectDescriptor, and the Equals
            method (used by TemplateMap)
          - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
            to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
            that a new feedback vector is always created for eval() containing tagged
            templates, even when the CompilationCache is used.
          - GetTemplateObject bytecode now takes a feedback index, and only calls
            into the runtime if the feedback is Smi::kZero (uninitialized).
      
      BUG=v8:3230, v8:2891
      R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
      rmcilroy@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
      Reviewed-on: https://chromium-review.googlesource.com/624564
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51248}
      d3ca0d00
  10. 03 Feb, 2018 1 commit
  11. 02 Feb, 2018 1 commit
  12. 29 Jan, 2018 1 commit
  13. 24 Jan, 2018 3 commits
  14. 11 Jan, 2018 1 commit
    • Caitlin Potter's avatar
      Reland "[esnext] load `iterator.next` only once at beginning of iteration" · 2d889aa9
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org
      TBR=neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: I9685db6e85315ba8a2df87a4537c2bf491e1e35b
      Reviewed-on: https://chromium-review.googlesource.com/857593
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50518}
      2d889aa9
  15. 09 Jan, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[esnext] load `iterator.next` only once at beginning of iteration" · 163b5d70
      Michael Achenbach authored
      This reverts commit bf4cc9ee.
      
      Reason for revert: Breaks windows with msvc and linux with gcc
      https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/841
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/17265
      
      Original change's description:
      > [esnext] load `iterator.next` only once at beginning of iteration
      > 
      > https://github.com/tc39/ecma262/pull/988 gained concensus during the
      > september 2017 TC39 meetings. This moves the load of the "next" method
      > to the very beginning of the iteration protocol, rather than during
      > each iteration step.
      > 
      > This impacts:
      > 
      > - yield*
      > - for-of loops
      > - spread arguments
      > - array spreads
      > 
      > In the v8 implementation, this also affects async iteration versions of
      > these things (the sole exception being the Async-From-Sync iterator,
      > which requires a few more changes to work with this, likely done in a
      > followup patch).
      > 
      > This change introduces a new AST node, ResolvedProperty, which can be used
      > as a callee by Call nodes to produce the same bytecode as Property calls,
      > without observably re-loading the property. This is used in several
      > AST-desugarings involving the iteration protocol.
      > 
      > BUG=v8:6861, v8:5699
      > R=​rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      > Reviewed-on: https://chromium-review.googlesource.com/687997
      > Commit-Queue: Caitlin Potter <caitp@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50452}
      
      TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,caitp@igalia.com,caitp@chromium.org
      
      Change-Id: I1797c0d596dfd6850d6f0f505f591a7a990dd1f1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6861, v8:5699
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/857616Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50454}
      163b5d70
    • Caitlin Potter's avatar
      [esnext] load `iterator.next` only once at beginning of iteration · bf4cc9ee
      Caitlin Potter authored
      https://github.com/tc39/ecma262/pull/988 gained concensus during the
      september 2017 TC39 meetings. This moves the load of the "next" method
      to the very beginning of the iteration protocol, rather than during
      each iteration step.
      
      This impacts:
      
      - yield*
      - for-of loops
      - spread arguments
      - array spreads
      
      In the v8 implementation, this also affects async iteration versions of
      these things (the sole exception being the Async-From-Sync iterator,
      which requires a few more changes to work with this, likely done in a
      followup patch).
      
      This change introduces a new AST node, ResolvedProperty, which can be used
      as a callee by Call nodes to produce the same bytecode as Property calls,
      without observably re-loading the property. This is used in several
      AST-desugarings involving the iteration protocol.
      
      BUG=v8:6861, v8:5699
      R=rmcilroy@chromium.org, neis@chromium.org, adamk@chromium.org
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Ib81106a0182687fc5efea0bc32302ad06376773b
      Reviewed-on: https://chromium-review.googlesource.com/687997
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50452}
      bf4cc9ee
  16. 08 Jan, 2018 1 commit
  17. 04 Jan, 2018 2 commits
  18. 19 Dec, 2017 2 commits
  19. 18 Dec, 2017 3 commits
  20. 15 Dec, 2017 3 commits
  21. 12 Dec, 2017 4 commits
    • Marja Hölttä's avatar
      [parser] Fix NaryOperation positions. · 10d9c314
      Marja Hölttä authored
      If an initializer is a NaryOperation, its position ends up as a start position
      of a Scope, and a DCHECK used to fire.
      
      Interestingly, this was not caught by our existing tests.
      
      BUG=chromium:791256
      
      Change-Id: Id47f850c7ad17ca580352f9bd56c9567b485c3b8
      Reviewed-on: https://chromium-review.googlesource.com/822093Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50051}
      10d9c314
    • Georg Neis's avatar
      Reland "Fix "this" value in lazily-parsed module functions." · 585b39f5
      Georg Neis authored
      This is a reland of c3bd741e
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      >
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      >
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      >
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org
      TBR=kozyatinskiy@chromium.org
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      
      Bug: chromium:791334
      Change-Id: I57acc7b84a345565b36cbb55924fa2ff9b449eec
      Reviewed-on: https://chromium-review.googlesource.com/822341
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50045}
      585b39f5
    • Michael Achenbach's avatar
      Revert "Fix "this" value in lazily-parsed module functions." · 62f09de9
      Michael Achenbach authored
      This reverts commit c3bd741e.
      
      Reason for revert: Breaks layout tests:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/20384
      
      Original change's description:
      > Fix "this" value in lazily-parsed module functions.
      > 
      > When preparsing top-level functions in a module, we didn't track
      > unresolved variables. Consequently, "this" ended up referencing
      > the global "this", which has the wrong value (in a module "this"
      > is supposed to be the undefined value).
      > 
      > This patch fixes that. This also lets us stop forcing context
      > allocation of all variables in module scopes, which the patch
      > takes care of as well.
      > 
      > Bug: chromium:791334
      > Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      > Reviewed-on: https://chromium-review.googlesource.com/808938
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#50025}
      
      TBR=adamk@chromium.org,marja@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
      
      Change-Id: I81f69334ed2ce104c00e6205d50001e4bdf07d15
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:791334
      Reviewed-on: https://chromium-review.googlesource.com/822258Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50036}
      62f09de9
    • Georg Neis's avatar
      Fix "this" value in lazily-parsed module functions. · c3bd741e
      Georg Neis authored
      When preparsing top-level functions in a module, we didn't track
      unresolved variables. Consequently, "this" ended up referencing
      the global "this", which has the wrong value (in a module "this"
      is supposed to be the undefined value).
      
      This patch fixes that. This also lets us stop forcing context
      allocation of all variables in module scopes, which the patch
      takes care of as well.
      
      Bug: chromium:791334
      Change-Id: Ifac1f1adc033f3facfb3d29dd4bca32ee27bffcf
      Reviewed-on: https://chromium-review.googlesource.com/808938Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50025}
      c3bd741e
  22. 01 Dec, 2017 1 commit
  23. 30 Nov, 2017 1 commit
  24. 27 Nov, 2017 2 commits
    • Adam Klein's avatar
      Move function name var initialization to BytecodeGenerator · bfa90f7e
      Adam Klein authored
      Besides avoiding the weird hack of inserting a statement at the 0th
      index of the function body, we also avoid allocating (and initializing)
      the variable if it's unreferenced (which I'd wager is the common case).
      
      Bug: v8:6092
      Change-Id: If917d422bb4818cf21e8272aa786ca84d4472802
      Reviewed-on: https://chromium-review.googlesource.com/784092Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49646}
      bfa90f7e
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored
      Previously, the class fields initializer function was stored on a
      synthetic context allocated variable. This approach had sevaral
      problems:
      
      - We didn't know that class literal had fields until after we had
      completely parsed the class literal. This meant that we had to go back
      and fix up the scope of the constructor to have this synthetic
      variable. This resulted in mismatch between parser and preparsed scope
      data.
      
      - This synthetic variable could potentially resolve to an initializer
      of an outer class.
      
      For ex:
      class X extends Object {
        c = 1;
        constructor() {
          var t = () => {
            class P extends Object {
              constructor() {
                var t = () => { super(); };
                t();
              }
            }
            super();
          }
          t();
        }
      }
      
      In this the inner class P could access the outer class X's initiliazer
      function. We would have to maintain extra metadata to make sure this
      doesn't happen.
      
      Instead this new approach uses a private symbol to store the
      initializer function on the class constructor itself.
      
      For the base constructor case, we can simply check for a bit on the
      constructor function literal to see if we need to emit code that loads
      and calls this initializer function. Therefore, we don't pay the cost
      of loading this function in case there are no class fields.
      
      For the derived constructor case, there are two possiblities:
      (a) We are in a super() call directly in the derived constructor:
      
      In this case we can do a check similar to the base constructor check,
      we can check for a bit on the derived constructor and emit code for
      loading and calling the initializer function.
      
      This is usually the common case and we don't pay any cost for not using
      class fields.
      
      (b) We are in a super() call inside an arrow function in the derived
      constructor:
      
      In this case, we /always/ emit code to load and call the initializer
      function. If the function doesn't exist then we have undefined and we
      don't call anything. Otherwise we call the function.
      
      super() can't be called twice so even if we emit code to load and call
      the initializer function multiple times, it doesn't matter because it
      would have already been an error.
      
      Bug: v8:5367
      Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
      Reviewed-on: https://chromium-review.googlesource.com/781660
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  25. 24 Nov, 2017 1 commit