- 10 Jul, 2020 1 commit
-
-
Igor Sheludko authored
... by migrating old-style code MyObject* obj = new (zone) MyObject(...) to the new style MyObject* obj = zone->New<MyObject>(...) Bug: v8:10689 Change-Id: Iec2b3102bd35ad7e50b90882ade78d27999a71f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288866Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68803}
-
- 12 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: chromium:1021444, chromium:1033196 Change-Id: Ic0468bce60577ad238581f17c4510a23ab63882a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1964390 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#65433}
-
- 11 Nov, 2019 2 commits
-
-
Santiago Aboy Solanes authored
Since smi-corrputing, TaggedSigned (aka known smis) only have the lower bits used. This renders CompressedSigned useless. Bug: v8:7703 Change-Id: Id59aaebc24d670ed32c483ceecf77fd194405ee4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903445 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64883}
-
Santiago Aboy Solanes authored
Including but not limiting to removing: * BitcastCompressedXXX * CheckedCompressedXXX * ChangeXXXToCompressedYYY * ChangeCompressedXXX As a note, ChangeTaggedToCompressed can't be removed just yet as it is still in use. Bug: v8:7703 Change-Id: I98cf88a32adfa976d419e69702d1cac4d3e811a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903435 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64880}
-
- 07 Nov, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Since the turbo_decompression_elimination flag is removed, there are several methods in machine-type.h that get simplified, e.g TypeCompressedTaggedPointer() can be replaced by just "TaggedPointer()". Also Removing the creation of Change to/from Compressed nodes. Removing these Change nodes' logic is left to a follow-up CL. Bug: v8:7703 Change-Id: Iff1f9aa8361189cf781a26317fd342b942fd5aa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1897537 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#64834}
-
- 16 Sep, 2019 1 commit
-
-
Tobias Tebbi authored
Bug: chromium:996097 Change-Id: I2d3bb6e1b844c1ffae0a5e44b1125593402fb7be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806675 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63798}
-
- 13 Sep, 2019 1 commit
-
-
Tobias Tebbi authored
This reverts commit 9ce67926. Reason for revert: This was never intended to stay. Original change's description: > [turbofan] temporarily disable const-based load elimination > > This is a safe to merge hot-fix to tackle https://crbug.com/983764. > To be reverted after merging to M77. > > Bug: chromium:983764 > Change-Id: I3cd27481f224b352ef6bcf9dde21a8f77616acff > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1786285 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63570} TBR=tebbi@chromium.org,mslekova@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:983764 Change-Id: I9c07eab384818aaeecab0224cec0f6b5310e9e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801839Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63743}
-
- 05 Sep, 2019 1 commit
-
-
Tobias Tebbi authored
This is a safe to merge hot-fix to tackle https://crbug.com/983764. To be reverted after merging to M77. Bug: chromium:983764 Change-Id: I3cd27481f224b352ef6bcf9dde21a8f77616acff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1786285Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63570}
-
- 28 Aug, 2019 1 commit
-
-
Maya Lekova authored
Remove unnecessary call to Serialize. Change a Handle cast to a Ref cast. Add a CHECK to JSHeapBroker::SetFeedback that the source is valid. Bug: v8:7790 Change-Id: I6a2f10d45456c6b128beff009016009457dc109c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773248 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63421}
-
- 23 Aug, 2019 1 commit
-
-
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}
-
- 16 Aug, 2019 2 commits
-
-
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}
-
Tobias Tebbi authored
This removes the restriction on load elimination to only track fields of representations with kTaggedSize, and instead also allows fields with representations using multiples of kTaggedSize (that is, Float64 and Word64 on pointer-compressed or 32-bit platforms). In order not to regress JIT-compile time for the common case of kTaggedSize-sized fields, we maintain information for bigger fields multiple times, once for each kTaggedSize-multiple offset that covers it. By checking that all copies of this information are still there when reading from the load elimination state, updates to the load elimination state don't need to take special care of bigger fields. Change-Id: I9b5f3d2d6e3b4f145c20d33fbc764869bf50a365 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752843 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63222}
-
- 24 Jul, 2019 1 commit
-
-
Jakob Gruber authored
Even in the most basic case (the task queue only ever contains a single element), this function triggers ~4KB in zone allocations. These allocations are basically lost and can never be reused. Avoid this by allocating inside a new temporary zone that is only alive during the ComputeLoopState function call. This reduces allocation size for the zone used during load elimination from ~30KB to ~15KB when compiling a trivial for-loop example. An alternative solution would be to switch to something similar to SmallVector (which uses a statically-sized stack storage before switching to heap allocations), but based on zones instead of malloc. Bug: v8:9427,v8:6150 Change-Id: Ic25abe6d48ac718c9ced2f9ef581f244030980fa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714869 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62883}
-
- 15 Jul, 2019 1 commit
-
-
Georg Neis authored
... by making them const or converting them to pointers. Bug: v8:9429 Change-Id: If4a7832944f5dc35cec04c11087499a552a7469a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700073 Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62705}
-
- 11 Jun, 2019 1 commit
-
-
Georg Schmid authored
R=machenbach@chromium.org, tebbi@chromium.org Change-Id: I99a5d5200ef7e0e812a2bf1e22a5f8ff813a1ca6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1653117Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#62098}
-
- 05 Jun, 2019 1 commit
-
-
Georg Schmid authored
R=tebbi@chromium.org Bug: chromium:964833 chromium:970120 Change-Id: I0fc179aa1e8fc5c13279342501f8639fce9ee7d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645315Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#61995}
-
- 04 Jun, 2019 1 commit
-
-
Georg Schmid authored
R=tebbi@chromium.org Bug: chromium:964833 Change-Id: I798f7c38eacaa16011ab7cc9ac4dea066078fbb5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643170Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#61977}
-
- 28 May, 2019 1 commit
-
-
Georg Schmid authored
Feedback pollution can create situations in which we statically see stores to the same field with incompatible representations; dynamically this should be impossible for a single TurboFan compilation unit. Instead of failing an assertion we produce Unreachable nodes. R=tebbi@chromium.org Bug: chromium:967434 chromium:967506 Change-Id: Id549ec84f28b4fed2d2e5ef05b40b48bc5b30e97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632169 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61894}
-
- 27 May, 2019 2 commits
-
-
Georg Schmid authored
R=jarin@google.com, tebbi@google.com Change-Id: Ic64ca132178f189a6d78a73ed18150ae503dd9a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617936 Auto-Submit: Georg Schmid <gsps@google.com> Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61844}
-
Georg Schmid authored
This is a reland of e588ff10 The only change over the original CL is found in JSCreateLowering::AllocateFastLiteral. We now guard against boilerplate values for unboxed double fields that *look* like legitimate initial values, but should really be kHoleNanInt64 instead. The underlying problem certainly existed before, but an invariant added to LoadElimination in this CL caused a Chromium layout test to fail. The change in this reland is therefore a workaround, the root cause remains to be fixed. Specifically, we find that a pointer to the undefined value oddball is sometimes reinterpreted as a double and assigned as a boilerplate value. @jarin suspects that this stems from in-place map updates. Original change's description: > Make LoadElimination aware of const fields (Part 2; stores) > > Adds const information to store field accesses and uses it in load elimination > > Change-Id: I00765c854c95c955dabd78557463267b95f75eef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Georg Schmid <gsps@google.com> > Cr-Commit-Position: refs/heads/master@{#61796} Change-Id: Ie388754890024a3ca7d10c9d4d7391442655b426 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630676Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#61838}
-
- 24 May, 2019 1 commit
-
-
Clemens Hammacher authored
This reverts commit e588ff10. Reason for revert: consistently crashes layout tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/32225 Original change's description: > Make LoadElimination aware of const fields (Part 2; stores) > > Adds const information to store field accesses and uses it in load elimination > > Change-Id: I00765c854c95c955dabd78557463267b95f75eef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Georg Schmid <gsps@google.com> > Cr-Commit-Position: refs/heads/master@{#61796} TBR=jarin@chromium.org,neis@chromium.org,tebbi@chromium.org,bmeurer@chromium.org,gsps@google.com Change-Id: Ia299c36b197c2aad7cfd953b06de06f4536ddb74 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627975Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61813}
-
- 23 May, 2019 2 commits
-
-
Georg Schmid authored
Adds const information to store field accesses and uses it in load elimination Change-Id: I00765c854c95c955dabd78557463267b95f75eef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Schmid <gsps@google.com> Cr-Commit-Position: refs/heads/master@{#61796}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 15 May, 2019 1 commit
-
-
Georg Schmid authored
Change-Id: I28f2c87ffae32d16bcfb7cb17ec6e607e7fa2285 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599172 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61506}
-
- 10 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Everything after UNREACHABLE is dead code, so it makes sense to remove them. Bug: v8:9183 Change-Id: If76468a73b926d74717cc2348fd5b36d30f680c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605727Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#61411}
-
- 08 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Going back on https://chromium-review.googlesource.com/c/v8/v8/+/1445978 since now 'tagged' means 'full tagged' again. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977, v8:7703 Change-Id: I3e39d631cc720a28577dad482dadfcc8332b6b18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593301 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#61339}
-
- 02 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
This is the first CL that aims to eliminate the straggler tagged loads and stores. Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977, v8:7703 Change-Id: If3782c0c7047d4c7d8669e12fb423cc0c74bc58a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587392Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#61180}
-
- 13 Mar, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:8977 Change-Id: I3bf6606d9db2369f5d82c71c5f58f6cf0c34bc0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520712 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#60220}
-
- 25 Feb, 2019 1 commit
-
-
Georg Neis authored
This was a pair of a set of maps and their common instance type (if any), but the instance type field was only used in a printing function. Removing the whole class in favor of ZoneHandleSet<Map> means we avoid looking at the heap to determine the common instance type. Eventually we can use the broker to do this if we need to. Bug: v8:7790 Change-Id: If0cadf9b17e3b9e77cffc4f0b69e2585aff7c85c Reviewed-on: https://chromium-review.googlesource.com/c/1481214Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59834}
-
- 04 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
This CL adds handling for Load/StoreMessage to LoadElimination. It is handled like a Load/StoreField to an external location. Change-Id: I50f27fba9cb7ffabf1474aa409083676cef65442 Bug: v8:8183, chromium:927746 Reviewed-on: https://chromium-review.googlesource.com/c/1451879 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59344}
-
- 19 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8562 Change-Id: I0dab49a03b74abc68600885f4951c5cb727a3d73 Reviewed-on: https://chromium-review.googlesource.com/c/1366736Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58364}
-
- 21 Nov, 2018 1 commit
-
-
Sigurd Schneider authored
Load elimination is running together with to dead code elimination, the latter of which might eliminate allocations (in particular FinishRegion nodes). These are treated as alias nodes by load elimination, and load elimination does not immediatelly learn that a node has been disconnected. This causes load elimination to access the inputs of dead code eliminated nodes while resolving renames, which causes nullptr dereferences. This CL modifies load elimination to not resolve to a nullptr alias but simply stop before that. Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5 Bug: chromium:906406 Reviewed-on: https://chromium-review.googlesource.com/c/1346491 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57688}
-
- 21 Sep, 2018 1 commit
-
-
Jakob Kummerow authored
GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class either derives from a class or has a member field of a type that was declared in an anonymous namespace. It is also opposed (-Werror=attributes) to visibility attributes being defined at explicit template instantiations. GCC 8.x further has reservations (-Werror=class-memaccess) about letting memset/memcpy modify areas within non-POD objects. Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a Reviewed-on: https://chromium-review.googlesource.com/1208306 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56106}
-
- 17 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
Cleanup the JSArrayBuffer bit fields to use the proper object macros that are now otherwise used consistently across the code base. Also change TurboFan to consistently bailout when it sees an array buffer that was previously neutered, so that the generic path / builtins are again the chokepoints for the spec violations (the fact that we don't always raise exceptions when we see a neutered array buffer), except for the ArrayBufferView accessor inlining in the JSCallReducer, where we still turn the values into zero (because we don't have access to a CALL_IC speculation guard in the common case). This also removes the ArrayBufferWasNeutered simplified operator, and does regular LoadField + Number bitwise operations instead, which is good enough and allows us to get rid of a lot of unnecessary complexity. Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178 Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947 Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55958}
-
- 24 Aug, 2018 4 commits
-
-
Benedikt Meurer authored
Thus far the LoadElimination didn't consider CheckHeapObject a renaming operation and would therefore miss opportunities to eliminate redundant loads or map checks where the input is not checked for sminess in all cases. This kind of pattern is very common with code that results from builtin inlining in JSCallReducer, as here we don't unconditionally insert CheckHeapObject nodes if we can tell from the graph that the receiver already has a certain map (by walking the effect chain upwards). Bug: v8:8070 Change-Id: I980f382205757a754f93a5741de1ee08b75ee070 Reviewed-on: https://chromium-review.googlesource.com/1188129Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55408}
-
Benedikt Meurer authored
This allows to replace redundant LoadField's whose type doesn't match the type of the replacement, by just turning those LoadField's into TypeGuard's. Bug: v8:8070 Change-Id: Ia329bb536f8829be27e070e90e9eaae0618dac7a Reviewed-on: https://chromium-review.googlesource.com/1188131Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55407}
-
Benedikt Meurer authored
The LoadElimination must be able to print Maps, so we need to allow handle dereferencing here. Change-Id: Id39a6db5a4f40ec6212404b3aa30a36fdd1ba57e Reviewed-on: https://chromium-review.googlesource.com/1188127 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55374}
-
Benedikt Meurer authored
In LoadElimination leverage the fact that initializing stores (i.e. stores to freshly allocated objects) cannot touch existing objects, since the object can only escape once it's fully initialized and then all accesses will happen on the FinishRegion node instead of the naked Allocate node. This helps to eliminate the redundant map checks and "length" accesses to arrays, since TurboFan now knows that the iterated array cannot alias with neither the freshly allocated ArrayIterator nor the freshly allocated IterResultObject instances. This improves the times on the benchmark in the tracking bug from console.timeEnd: forOf, 188.111000 console.timeEnd: traditional, 116.380000 console.timeEnd: forOf, 170.721000 console.timeEnd: traditional, 108.209000 console.timeEnd: forOf, 168.491000 console.timeEnd: traditional, 108.839000 to console.timeEnd: forOf, 192.501000 console.timeEnd: traditional, 106.909000 console.timeEnd: forOf, 138.364000 console.timeEnd: traditional, 103.232000 console.timeEnd: forOf, 138.755000 console.timeEnd: traditional, 102.928000 when running with untrusted code mitigations turned off, and thus corresponds to a ~18% performance improvement, roughly cutting the performance difference between the traditional for loop and the for..of loop in half. Besides for..of loops this will also help with array destructuring patterns where TurboFan also emitted redundant map checks on the array and didn't eliminate the redundant "length" accesses. Bug: v8:8070 Change-Id: Iab283247f6d304d1e3c7c147f32ab957577aad21 Reviewed-on: https://chromium-review.googlesource.com/1188124Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55373}
-
- 15 Jun, 2018 1 commit
-
-
Leszek Swirski authored
Bug: v8:7786 Change-Id: I1e568ff6da02dfd92b24b8badd665096cf49a13a Reviewed-on: https://chromium-review.googlesource.com/1101321Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#53747}
-
- 14 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
This is a reland of 0909dbe3. Added missing V8_EXPORT_PRIVATE to AndroidLogStream. TBR=mstarzinger@chromium.org Original change's description: > Introduce StdoutStream which prints to Android log or stdout > > The often used construct {OFStream(stdout)} does not work on Android. > This CL introduces an {StdoutStream} which behaves exactly like > {OFStream(stdout)} on non-android platforms, and redirects to the > Android log on appropriate systems and configurations. > > R=mstarzinger@chromium.org > > Bug: v8:7820 > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b > Reviewed-on: https://chromium-review.googlesource.com/1088911 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53692} Bug: v8:7820 Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58 Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53733}
-