- 12 Sep, 2019 1 commit
-
-
Michael Starzinger authored
This fixes the case where a table entry contains a function constructed via {WebAssembly.Function} and is then read out via a runtime function from the table. R=ahaas@chromium.org TEST=mjsunit/regress/wasm/regress-crbug-1002388 BUG=chromium:1002388 Change-Id: Ic0a9a544baaf37e68cd22eb91f2ef0bdf5fa5842 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795352Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63709}
-
- 11 Sep, 2019 1 commit
-
-
Michael Lippautz authored
Do not assume that the MaybeHandle that is returned when fetching for a property is valid and instead check for its contents. Treat an empty handle as not finding the right property. Bug: chromium:1002827 Change-Id: Iac158086ec5f66cd9602f4a73ae78de367dd3e77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796556 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#63672}
-
- 10 Sep, 2019 2 commits
-
-
Mythri A authored
We don't handle all cases for stores to typed arrays in the builtins related to storing a property. Bailout to runtime when storing into a typed array if the property is not found on the object. Bug: chromium:996161 Change-Id: I684c7c4f526b15cdfb5bfe3fd23218910486a59e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789396 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#63639}
-
Dan Elphick authored
When analyzing functions scopes with the script_scope as parent, don't skip migrating unresolved variables upwards if we could still be inside an arrow head, which means accesses to those variables will be correctly context allocated. Bug: v8:8510, chromium:1000094 Change-Id: I684f2f8bc692de420203990f93e5c943b5b769c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789705Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63635}
-
- 05 Sep, 2019 3 commits
-
-
Clemens Hammacher authored
{JavaScriptFrame::GetParameters} allocates a new {FixedArray}, hence all object references need to be handified to survive that allocation. R=mstarzinger@chromium.org Bug: chromium:1000635 Change-Id: I76df5ac109bdb6999fe897bdafaf2175344ecca4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787429Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63583}
-
Leszek Swirski authored
This is a reland of 981aafaf It adds double checks to LoadFieldByIndex in the optimizing compiler, which are likely the source of the crashes. Original change's description: > Reland "[ic] In-place Double -> Tagged transitions" > > This is a reland of 0736599a. > This is a reland of 7e1fbe8f. > > Original change description: > > [ic] In-place Double -> Tagged transitions > > > > With no more MutableHeapNumber, we can make Double -> Tagged transitions > > in-place, at the cost of an extra map check when accessing double fields > > to make sure they are still doubles. > > > > Bug: v8:9606 > > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63374} > > TBR=verwaest@chromium.org, tebbi@chromium.org > > Bug: v8:9606 > Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63499} TBR=verwaest@chromium.org Bug: v8:9606 Bug: chromium:997989 Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63582}
-
Dan Elphick authored
Since const variables are immutable, ignore SetMaybeAssigned for them. Bug: chromium:999450, chromium:1000170, v8:8510 Change-Id: Idc1b71677b3d03bb63cc025017c119710b8f392d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782170 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63579}
-
- 04 Sep, 2019 2 commits
-
-
Leszek Swirski authored
This reverts commit 981aafaf. Reason for revert: Still crashing on Canary. Original change's description: > Reland "[ic] In-place Double -> Tagged transitions" > > This is a reland of 0736599a. > This is a reland of 7e1fbe8f. > > Original change description: > > [ic] In-place Double -> Tagged transitions > > > > With no more MutableHeapNumber, we can make Double -> Tagged transitions > > in-place, at the cost of an extra map check when accessing double fields > > to make sure they are still doubles. > > > > Bug: v8:9606 > > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63374} > > TBR=verwaest@chromium.org, tebbi@chromium.org > > Bug: v8:9606 > Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63499} TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9606 Bug: chromium:997989 Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63550}
-
Dan Elphick authored
Use the position of commas in async arrow expressions to mark the initializer position of any parameters that might have been set in the preceding parameter. This extends https://chromium-review.googlesource.com/c/v8/v8/+/1710671 to async arrow heads. Bug: v8:8510, chromium:997320 Change-Id: I98e0ac817c7f53fbf1dced98fb6891a386ee7803 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781057Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63542}
-
- 03 Sep, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org TEST=mjsunit/wasm/asm-wasm-math-intrinsic BUG=v8:8505 Change-Id: I883c9ad174f7fda5ec5dd24e71ca674de51239b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782160Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63521}
-
- 02 Sep, 2019 1 commit
-
-
Leszek Swirski authored
This is a reland of 0736599a. This is a reland of 7e1fbe8f. Original change description: > [ic] In-place Double -> Tagged transitions > > With no more MutableHeapNumber, we can make Double -> Tagged transitions > in-place, at the cost of an extra map check when accessing double fields > to make sure they are still doubles. > > Bug: v8:9606 > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63374} TBR=verwaest@chromium.org, tebbi@chromium.org Bug: v8:9606 Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63499}
-
- 30 Aug, 2019 1 commit
-
-
Dan Elphick authored
When changing the code coverage or type profiler modes, first ensure there are source positions for all BytecodeArrays as regenerating the source positions after toggling the mode will result in a bytecode mismatch. Bug: v8:9656, v8:8510 Change-Id: Ic6cf3afec1588f11e5ce5fcbea2fd13e4452e15f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774721 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63484}
-
- 29 Aug, 2019 2 commits
-
-
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:
Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63455}
-
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:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63441}
-
- 28 Aug, 2019 3 commits
-
-
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:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63432}
-
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:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63430}
-
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:
Erik Corry <erikcorry@chromium.org> Cr-Commit-Position: refs/heads/master@{#63424}
-
- 26 Aug, 2019 2 commits
-
-
Toon Verwaest authored
By marking maps detached from the transition tree as prototypes, we'll automatically stop tracking transitions from those detached fast maps. That allows us to quickly check whether a map is detached (or the initial map anyway); and saves memory. We can use this information to ignore sibling type feedback when parsing a JSON array with many distinctly shaped json objects. Bug: chromium:993980 Change-Id: I86d493ac2cabec2c31c6e322ad5c5a7ace059dfc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771778Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63403}
-
Leszek Swirski authored
For stores with Double feedback, StoreIC needs to check that the representation is still Double before doing the store, in case it accidentally tries to write to an object or worse, mutate a non-mutable HeapNumber. Bug: v8:9606 Bug: chromium:997485 Change-Id: I51e0953b40f752648c5e86b8644c23baf636367e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768373 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63402}
-
- 23 Aug, 2019 4 commits
-
-
Georg Schmid authored
Even when a field is marked const, we may emit multiple consecutive in-literal stores to that field. That is, in 'JSNativeContextSpecialization::BuildPropertyStore', when the access mode is 'kStoreInLiteral' and we are accessing a const field, we may produce a StoreField node, even though another StoreField (that stores something other than 'Uninitialized') to the same const field dominates it. This appears to be sound, since earlier stores to literals cannot be observed anyways. Unfortunately this behavior conflicts with the double const store invariant in load elimination: Roughly speaking, we assume that load elimination may never observe two consecutive const stores to the same field on the same object. The apparent solution would be to treat 'kStoreInLiteral' accesses like regular 'kStore' accesses: For consecutive stores to const properties we don't emit StoreField, but instead emit code that checks whether the value about to be written is equivalent to the previously written one, and otherwise deopt ('DeoptimizeReason::kWrongValue'). Unfortunately this turns out impractical, since for 'kStoreInLiteral' accesses we can't easily decide whether we're dealing with the first such store or one of the consecutive ones. Also see this abandoned CL: https://chromium-review.googlesource.com/c/v8/v8/+/1762020. This CL instead adds an exception to the invariant in load elimination. We track whether a store arose from a 'kStoreInLiteral' access, and use this information when visiting StoreField nodes in load elimination. R=neis@chromium.org, tebbi@chromium.org Bug: chromium:987205 Change-Id: I8829752aa0637e9599677d20aad2d706d40d7fe6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763535Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#63385}
-
Joshua Litt authored
In order to reflect web reality, TC39 has made some slight changes to name descriptors, see https://github.com/tc39/ecma262/pull/1490 for details. V8 was mostly already in compliance with these changes, but ThrowTypeError and anonymous classes needed some slight changes. Bug: v8:9646 Change-Id: I163238954938f0c005e3adbc61b90498e01436da Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63373}
-
Maya Lekova authored
Bug: chromium:997057 Change-Id: I821b91ff51f82e6325dae5719e1669142c82b05e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768579 Commit-Queue: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Auto-Submit: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63369}
-
Ana Peško authored
is enabled. Change-Id: Iab87b9c7a0d0600782b02537844338ff065622ab Bug: chromium:996234 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1765531Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Ana Pesko <anapesko@google.com> Cr-Commit-Position: refs/heads/master@{#63360}
-
- 20 Aug, 2019 2 commits
-
-
Leszek Swirski authored
Since the mutability of HeapNumbers is determined by their owning object's descriptor array, we can remove the MutableHeapNumber type entirely, at the cost of a few fewer DCHECKs and a couple of TODOs to use the descriptor array information. This is a necessary step towards a follow-up which allows in-place Double -> Tagged transitions Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/ Bug: v8:9606 Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63294}
-
Dan Elphick authored
Fixes bytecode mismatch between lazy and non-lazy where "this" was marked as maybe assigned in constructors that called the super constructor. Since this will return the hole in cases where it was not yet initialized by super (and the hole is explicitly handled by JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as a constant in all cases. In the case of lazy compilation case, "this" is never added to the ScopeInfo so is never seen as mutable. Bug: chromium:994719 Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63283}
-
- 19 Aug, 2019 1 commit
-
-
Z Nguyen-Huu authored
This is a reland of f54f92dd. Fix IsFastRegExpPermissive to call BranchIfFastRegExp_Permissive. Original change's description: > [builtins] Port RegExpTest to Torque > > Bug: v8:8976 > Change-Id: Ia4dc120a31eb363599b47b22b749a3146a9c7c73 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746083 > Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63211} Bug: v8:8976, chromium:994041 Change-Id: I86c9c66b060f47164515e29f914b95456c233d30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1756390 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63255}
-
- 16 Aug, 2019 1 commit
-
-
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:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63226}
-
- 14 Aug, 2019 2 commits
-
-
Dan Elphick authored
Fixes DCHECK failure in DropStackFrameCacheCommon by returning early if the source_position_table is Exception. Bug: chromium:990582, v8:8510 Change-Id: I671f3e0cdc9f880dedf8ecd2fffb1083229dc6dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752856Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63209}
-
Ross McIlroy authored
Otherwise there is a mismatch between eager parsing (where the reciever is marked as MaybeAssigned) and lazy parsing (where the receiver is deserialized and not marked MaybeAssigned) for arrow functions that have an inner scope that calls eval. BUG=chromium:989914 Change-Id: I8b8b78140858985a75a971b0e0a95bd61463457b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752851Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63206}
-
- 13 Aug, 2019 2 commits
-
-
Patrick Thier authored
When GC triggered while an exception is pending, a read to memory that was no longer valid could happen while backtracking in the regexp interpreter (introduced with commit fb0df2c8). This CL prevents this dirty read, that could have been a security issue. Bug: chromium:992389, v8:9575 Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342 Commit-Queue: Patrick Thier <pthier@google.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63195}
-
Ross McIlroy authored
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value. However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_ and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a unittest and the clusterfuzz script which highlighted the issue. BUG=chromium:991133 Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63190}
-
- 08 Aug, 2019 1 commit
-
-
Peter Marshall authored
The spec says we have to insert some wrapper code with extra line breaks in it, but this confuses users when they see stack traces as the line numbers come from the code with the wrapper, instead of the original. This CL sets line_offset on the script to indicate that line numbers should be offset by the 2 extra line breaks when reading them out e.g. for the purpose of stack traces. Bug: chromium:109362 Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#63127}
-
- 05 Aug, 2019 1 commit
-
-
Joshua Litt authored
When a fast path was added for Math.hypot, the algorithm was also simplified. This simplification turns out to be incorrect in some rare edge cases. This cl reverts back to the original algorithm and converts it to torque. Original cl: https://chromium-review.googlesource.com/c/v8/v8/+/1684178 Bug: v8:9546 Change-Id: If4e21504732f46081a8de823f50f499917f1a20c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725200 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63070}
-
- 02 Aug, 2019 1 commit
-
-
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:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63051}
-
- 01 Aug, 2019 1 commit
-
-
Maya Lekova authored
When the flag is on and some of the functions don't have bytecode, we should gracefully print "no bytecode" instead of crashing. Bug: chromium:983267 Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63031}
-
- 31 Jul, 2019 1 commit
-
-
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:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63009}
-
- 30 Jul, 2019 3 commits
-
-
Toon Verwaest authored
The DCHECK related to a time when dictionary mode prototypes were the payload of complex data driven handlers. Now the additional data is used to hold entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning up the names makes this clearer. Bug: chromium:986187 Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#62993}
-
Toon Verwaest authored
This drops possible remaining pattern errors from the access target. This is necessary since sub patterns with default values (assignment expression) aren't otherwise identifiable as being property accesses. Bug: v8:9560 Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62982}
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I31502a8023564e88e0a28a421e3c7fb3404847dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722566 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62973}
-
- 29 Jul, 2019 1 commit
-
-
Dan Elphick authored
Fixes a bytecode mismatch for arrow functions with default arguments between eager and lazy compilation. In the former case, parameters with default values are marked as assigned even if the value never changes within the function because the parser does not know it's an arrow-function at the point it sees the assignment. So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear the is_assigned flag on its parameter VariableProxies before it binds them. Bug: chromium:988304, v8:8510 Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#62962}
-