1. 12 Sep, 2019 1 commit
  2. 11 Sep, 2019 1 commit
  3. 10 Sep, 2019 2 commits
  4. 05 Sep, 2019 3 commits
  5. 04 Sep, 2019 2 commits
  6. 03 Sep, 2019 1 commit
  7. 02 Sep, 2019 1 commit
  8. 30 Aug, 2019 1 commit
  9. 29 Aug, 2019 2 commits
    • Leszek Swirski's avatar
      [scopes] Push sloppy eval check through eval scopes · f6057ff1
      Leszek Swirski authored
      Sloppy eval extends the outer declaration scope's context. This is also
      true for sloppy eval inside of other sloppy evals -- the outer declaration
      scope's context is extended rather than the outer sloppy eval's
      declaration scope. However, we consider eval scopes to also be declaration
      scopes, for the purposes of strict eval and caching lookup variables. So,
      we need to make sure that we skip through sloppy eval scopes when marking
      a scope as calls_sloppy_eval.
      
      In fact, we implement this rather as never marking sloppy eval scopes as
      calls_sloppy_eval, under the assumption that the parent scope will already
      have been marked calls_sloppy_eval by the outer eval.
      
      As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
      RecordEvalCall(), rename the variable to something more meaningful, and
      make Snapshotting to use a new calls_eval bit on Scope.
      
      Bug: chromium:996751
      Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63455}
      f6057ff1
    • Leszek Swirski's avatar
      Revert "[ic] In-place Double -> Tagged transitions" · e39c7019
      Leszek Swirski authored
      This reverts commit 0736599a.
      This reverts commit 7e1fbe8f.
      
      Reason for revert: Still some crashes, reverting to unblock dev.
      
      TBR=ishell@chromium.org,tebbi@chromium.org
      
      Bug: v8:9606
      Bug: chromium:997485
      Bug: chromium:997989
      Change-Id: I9a0cb5440bf4fce06c9e6134dacf5c03d512f049
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773271
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63441}
      e39c7019
  10. 28 Aug, 2019 3 commits
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored
      Currently the backing store and elements kind might not aligned aka
      backing store can be dictionary where elements kind is frozen/sealed
      element kinds or the other way around. The reason is that
      Object.preventExtensions change elements kind to DICTIONARY while
      Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
      Apply both these operations can lead to that problem as in
      chromium:992914
      
      To solve this issue, we avoid Object.preventExtensions to change backing
      store to dictionary by introducing new nonextensible elements kind.
      These new nonextensible elements kind are handled similar to frozen,
      sealed element kinds. This change not only fixes the problem but also
      optimize the performance of nonextensible objects.
      
      Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
      Bug: chromium:992914, v8:6831
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
    • Sigurd Schneider's avatar
      [runtime] Throw range error on too many properties · 44770974
      Sigurd Schneider authored
      This change allows the KeyAccumulator to throw a range error if there
      are too many properties to be enumerated.
      
      This CL introduces extensive checks during key enumeration in the run-time,
      and might introduce regressions. If so, feel free to revert.
      
      Bug: chromium:918301
      Change-Id: I6166c0b15f1a05eac7116a979f12ba4833d1d1b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545902
      Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-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@{#63430}
      44770974
    • Jakob Gruber's avatar
      [regexp] Dont attempt to match '^' before the start of the string · 1990b1e1
      Jakob Gruber authored
      This fixes an invalid assumption when emitting code for matching '^'
      (start of line) in multiline regexps and '\b', '\B' in general.
      
      What we used to do: if the current trace's cp_offset (the offset from
      the current position) was non-zero, we assumed that we were looking at
      subject string index 1 or greater (i.e.: not at the start of the string
      or before).
      
      This is no longer valid since cp_offsets can now be negative.
      
      This CL changes the logic to omit start- and bounds-checks only for
      strictly positive cp_offsets, where the above assumption still holds.
      
      Bug: chromium:996391
      Change-Id: I79be4fc295c6f0b63e41c13d1e91fdd00f2f2b42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771794
      Commit-Queue: Erik Corry <erikcorry@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarErik Corry <erikcorry@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63424}
      1990b1e1
  11. 26 Aug, 2019 2 commits
  12. 23 Aug, 2019 4 commits
  13. 20 Aug, 2019 2 commits
  14. 19 Aug, 2019 1 commit
  15. 16 Aug, 2019 1 commit
    • Georg Schmid's avatar
      [turbofan] Track field owner maps during load elimination · f85826ea
      Georg Schmid authored
      This CL adds additional information in PropertyAccessInfos and FieldAccesses about the map that introduced the accessed field. We use this information to prevent load elimination from incorrectly optimizing certain accesses marked const.
      
      Prior to this CL, load elimination simply stored information about eliminatable field accesses based on objects (identified by nodes in the graph) and offsets (i.e., statically known ones). In the presence of const stores and loads this is insufficient, since a single object (in the above sense) may contain distinct *const* properties at the same offset throughout its lifetime. As an example, consider the following piece of code:
      
          let obj = {};
          obj.a = 0;
          obj[1024] = 1;  // An offset of >=1024 forces an elements-kind transition
          delete obj.a;
          obj.b = 2;
          assertEquals(obj.b, 2);
      
      In this scenario, *both* the first ('obj.a = 0') and the second ('obj.b = 2') store to a field will be marked const by the runtime. The reason that storing to 'a' above ends up being marked const, is that 'a' before and after the elements-kind transition is encoded in separate transition trees. Removing 'a' ('delete obj.a') only invalidates const-ness in the dictionary-elements transition tree; not the holey-elements one used at the time of 'obj.a = 0'.
      
      The above situation on its own violates an invariant in load elimination. Namely, we assume that for the same object and offset, we will never encounter two const stores. One can extend the above snippet to coax load-elimination into producing incorrect results. For instance, by "hiding" 'obj.b = 2' in an unoptimized function call, the consecutive load from 'b' will incorrectly produce 0, violating the assert.
      
      R=neis@chromium.org, tebbi@chromium.org
      
      Bug: chromium:980183, chromium:983764
      Change-Id: I576a9c7efd416fa9db6daff1f42d483e4bd369b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751346
      Commit-Queue: Georg Schmid <gsps@google.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63226}
      f85826ea
  16. 14 Aug, 2019 2 commits
  17. 13 Aug, 2019 2 commits
  18. 08 Aug, 2019 1 commit
  19. 05 Aug, 2019 1 commit
  20. 02 Aug, 2019 1 commit
    • Leszek Swirski's avatar
      [scopes] Skip dynamic vars in eval scopes during lookup · 9cf089e9
      Leszek Swirski authored
      For variable proxies in a function inside an eval scope that point to
      a dynamic variable in the eval scope, the current scope resolution will
      find this variable only when the function is eagerly compiled, as the
      eval scope only exists during top-level eval compilation. This causes
      a mismatch between lazy- and eager- compiled functions.
      
      With this patch, we skip these dynamic variables during lookup, so that
      the lookup for the variable proxy always finds a kDynamicLocal or
      kDynamicGlobal, both when compiled lazily and eagerly. This is a minor
      pessimisation of performance (as we know that the lookup has to be
      dynamic), but unblocks other improvements which require idempotent
      bytecode generation (such as lazy source positions).
      
      Note that the alternative, of simply not tracking dynamic variables on
      the eval scope at all, is not viable due to needing this information
      during conflict detection.
      
      Bug: v8:8510
      Bug: v8:9511
      Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63051}
      9cf089e9
  21. 01 Aug, 2019 1 commit
  22. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "[regexp] Better quick checks on loop entry nodes" · bea0ffd0
      Seth Brenith authored
      This is a reland of 4b15b984
      
      Updates since original: fix an arithmetic overflow bug, remove an invalid
      DCHECK, add a unit test that would trigger that DCHECK.
      
      Original change's description:
      > [regexp] Better quick checks on loop entry nodes
      >
      > Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
      > change is inspired by attempting to exit earlier from generated RegExp
      > code, when no further matches are possible because any match would be
      > too long. The motivating example this time is the following expression,
      > which tests whether a string of Unicode playing cards has five of the
      > same suit in a row:
      >
      > /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
      >
      > A human reading this expression can readily see that any match requires
      > at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
      > each repeated option reports its minimum distance to the end of a match
      > as zero. This is correct, because the LoopChoiceNode's behavior depends
      > on additional state (the loop counter). However, the preceding node, a
      > SET_REGISTER action that initializes the loop counter, could confidently
      > state that it consumes at least 10 characters. Furthermore, when we try
      > to emit a quick check for that action, we could follow only paths from
      > the LoopChoiceNode that are possible based on the minimum iteration
      > count. This change implements both of those "could"s.
      >
      > I expect this improvement to apply pretty broadly to expressions that
      > use minimum repetition counts and that don't meet the criteria for
      > unrolling. In this particular case, I get about 12% improvement on the
      > overall UniPoker test, due to reducing the execution time of this
      > expression by 85% and the execution time of another similar expression
      > that checks for n-of-a-kind by 20%.
      >
      > Bug: v8:9305
      >
      > Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62963}
      
      Bug: v8:9305
      Change-Id: I992070d383009013881bf778242254c27134b650
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63009}
      bea0ffd0
  23. 30 Jul, 2019 3 commits
  24. 29 Jul, 2019 1 commit