- 27 May, 2019 1 commit
-
-
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 3 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}
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 15 May, 2019 1 commit
-
-
Benedikt Meurer authored
Previously we had to use CheckHeapObject in front of every CheckMaps, CompareMaps and TransitionElementsKind operation. Now these operators request HeapObject representation themselves (requiring for CompareMaps and TransitionElementsKind to remove the kNoDeopt property). This means we only do CheckHeapObject for StoreField to a field that has HeapObject representation. This not only leads to smaller graphs in the compiler, but also removes most uses of the CheckHeapObject operator, which doesn't express a real semantic property in the compiler frontend. Bug: v8:9183, v8:9250 Refs: nodejs/node#27667 Change-Id: Ie3d83de69583b1bed6c1c53444bfc97aaef624bb Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612902Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61508}
-
- 14 May, 2019 1 commit
-
-
Benedikt Meurer authored
This is a preparation for doing a similar change to JSTypedArrays to be able to finally access huge ArrayBuffers with TypedArrays. This CL itself improves the performance of DataViews, sometimes to be even faster than TypedArrays now. On the test case[1] we go from testDataViewGetUint8: 711 ms. testUint8Array: 654 ms. testDataViewGetUint16: 801 ms. testUint16Array: 649 ms. testDataViewGetInt32: 699 ms. testInt32Array: 648 ms. testDataViewGetFloat64: 701 ms. testFloat64Array: 650 ms. to testDataViewGetUint8: 622 ms. testUint8Array: 656 ms. testDataViewGetUint16: 634 ms. testUint16Array: 656 ms. testDataViewGetInt32: 629 ms. testInt32Array: 655 ms. testDataViewGetFloat64: 631 ms. testFloat64Array: 661 ms. so the performance improves by up to **20%**. [1] https://github.com/bmeurer/js-micro-benchmarks/blob/master/bench-dataview.js Tbr: ulan@chromium.org Bug: chromium:225811, v8:4153, v8:8383 Change-Id: Ie4409e2fe96e5085ddcf5eb3f24f3cacfb3afe02 Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601144 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#61464}
-
- 09 May, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Going back on https://chromium-review.googlesource.com/c/v8/v8/+/1480382 since now 'tagged' means 'full tagged' again. I am keeping the access builder since that seems useful to have (as opposed to building the access builder in the implementation). 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, v8:9206 Change-Id: I7c38b090190aa1c3e91c5ab9f729588aeae2dc1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594439 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61371}
-
- 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}
-
- 24 Apr, 2019 1 commit
-
-
Tobias Tebbi authored
Add suport for large object space allocations in Turbofan and use it from CSA when young large objects are enabled. This maintains the Turbofan invariant that the generation is statically predictable. In principle, this enables write barrier elimination for large objects allocated from Torque/CSA. But it doesn't seem to trigger much yet, probably we have to improve the MemoryOptimizer. Bug: v8:7793 Change-Id: I7ea7d0cb549573db65fafe5df5edf67e0ce90893 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565905Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#60984}
-
- 18 Apr, 2019 2 commits
-
-
Georg Neis authored
We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b70118. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 57582090. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0e. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
-
Jaroslav Sevcik authored
This uses the same comparison as the ICs to make sure that ICs learn after deoptimization (see https://chromium-review.googlesource.com/c/v8/v8/+/1561319 for the IC fix). Bug: v8:9139 Change-Id: I67a361d85ee0c8a4ad4a6abc2d33ac4ca5fa22bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569438 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60917}
-
- 11 Apr, 2019 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:9113 Change-Id: I413d9df34f0bdea9c30db33ad79891218e229341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564053Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#60776}
-
- 03 Apr, 2019 1 commit
-
-
Santiago Aboy Solanes authored
Includes both changing from compressed pointers and to compressed pointers. Also added tests to the representation changer test B Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng Bug: v8:8977 Change-Id: I8a13f6b7ec2208442aa354949173cc9061bce168 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533866Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#60587}
-
- 19 Mar, 2019 1 commit
-
-
Benedikt Meurer authored
This change significantly improves the performance of string concatenation in optimized code for the case where the resulting string is represented as a ConsString. On the relevant test cases we go from serializeNaive: 10762 ms. serializeClever: 7813 ms. serializeConcat: 10271 ms. to serializeNaive: 10278 ms. serializeClever: 5533 ms. serializeConcat: 10310 ms. which represents a 30% improvement on the "clever" benchmark, which tests specifically the ConsString creation performance. This was accomplished via a couple of different steps, which are briefly outlined here: 1. The empty_string gets its own map, so that we can easily recognize and handle it appropriately in the TurboFan type system. This allows us to express (and assert) that the inputs to NewConsString are non-empty strings, making sure that TurboFan no longer creates "crippled ConsStrings" with empty left or right hand sides. 2. Further split the existing String types in TurboFan to be able to distinguish between OneByte and TwoByte strings on the type system level. This allows us to avoid having to dynamically lookup the resulting ConsString map in case of ConsString creation (i.e. when we know that both input strings are OneByte strings or at least one of the input strings is TwoByte). 3. We also introduced more finegrained feedback for the Add bytecode in the interpreter, having it collect feedback about ConsStrings, specifically ConsOneByteString and ConsTwoByteString. This feedback can be used by TurboFan to only inline the relevant code for what was seen so far. This allows us to remove the Octane/Splay specific magic in JSTypedLowering to detect ConsString creation, and instead purely rely on the feedback of what was seen so far (also making it possible to change the semantics of NewConsString to be a low-level operator, which is only introduced in SimplifiedLowering by looking at the input types of StringConcat). 4. On top of the before mentioned type and interpreter changes we added new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and CheckNonEmptyTwoByteString, which perform the appropriate (dynamic) checks. There are several more improvements that are possible based on this, but since the change was already quite big, we decided not to put everything into the first change, but do some follow up tweaks to the type system, and builtin optimizations later. Tbr: mstarzinger@chromium.org Bug: v8:8834, v8:8931, v8:8939, v8:8951 Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: https://bit.ly/fast-string-concatenation-in-javascript Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60318}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 25 Feb, 2019 2 commits
-
-
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}
-
Santiago Aboy Solanes authored
since these operators don't have any variable arguments. Bug: v8:8183 Change-Id: I602fe65a2137d6ffc6ece702da53d660577eee4a Reviewed-on: https://chromium-review.googlesource.com/c/1482736Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59819}
-
- 22 Feb, 2019 1 commit
-
-
Santiago Aboy Solanes authored
This now makes it so TurboFan now uses full pointer loads for arguments values located on stack. Bug: v8:8876, v8:7703 Change-Id: Ib82d6f3b0f4c8d33669c7f86ce803381d210c019 Reviewed-on: https://chromium-review.googlesource.com/c/1480382Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59798}
-
- 13 Feb, 2019 1 commit
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
- 08 Feb, 2019 1 commit
-
-
Jaroslav Sevcik authored
Instead of eliminating bounds checks based on types, we introduce an aborting bounds check that crashes rather than deopts. Bug: v8:8806 Change-Id: Icbd9c4554b6ad20fe4135b8622590093679dac3f Reviewed-on: https://chromium-review.googlesource.com/c/1460461 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59467}
-
- 31 Jan, 2019 1 commit
-
-
Sigurd Schneider authored
These allow to write a tagged uncompressed pointer even if pointer compression is enabled. This is the least intrusive option; once TurboFan supports pointer compression better, this CL likely needs to be revised. Bug: v8:8183 Change-Id: I56451c364b8620f687d8b9deb9553099ba95b928 Reviewed-on: https://chromium-review.googlesource.com/c/1445978 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59247}
-
- 02 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
Introduce a LeakyObject template and use that to implement static lazily initialized objects that never get destructed. This was done in a hand-crafted and complex way before via LazyInstance and LazyStaticInstance. R=tebbi@chromium.org Bug: v8:8600, v8:8562 Change-Id: Id160996753b2cb1baf0f4b2cec9e1727f1d01512 Reviewed-on: https://chromium-review.googlesource.com/c/1388539 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58494}
-
- 09 Nov, 2018 1 commit
-
-
Benedikt Meurer authored
Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`, but this will yield the wrong results when `x` is a subnormal, i.e. really close to 0. In CSA we already perform bit checks to test for -0, so teach TurboFan to do the same for comparisons to -0 (via `Object.is`). We introduce a new NumberIsMinusZero simplified operator to handle the case where SimplifiedLowering already knows that the input is a number. Bug: chromium:903043, v8:6882 Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4 Reviewed-on: https://chromium-review.googlesource.com/c/1328802 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#57382}
-
- 29 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This introduces Word64 support for the CheckBounds operator, which now lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the representation selection. The right hand side of CheckBounds can now be any positive safe integer on 64-bit architectures, whereas it remains Unsigned31 for 32-bit architectures. We only use the extended Word64 support when the right hand side is outside the Unsigned31 range, so for everything except DataViews this means that the performance should remain the same. The typing rule for the CheckBounds operator was updated to reflect this new behavior. The CheckBounds with a right hand side outside the Unsigned31 range will pass a new Signed64 feedback kind, which is handled with newly introduced CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation selection. The JSCallReducer lowering for DataView getType()/setType() methods was updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore, but instead just use the raw uintptr_t values and operate on any value (for 64-bit architectures these fields can hold any positive safe integer, for 32-bit architectures it's limited to Unsigned31 range as before). This means that V8 can now handle huge DataViews fully, without falling off a performance cliff. This refactoring even gave us some performance improvements, on a simple micro-benchmark just exercising different DataView accesses we go from testDataViewGetUint8: 796 ms. testDataViewGetUint16: 997 ms. testDataViewGetInt32: 994 ms. testDataViewGetFloat64: 997 ms. to testDataViewGetUint8: 895 ms. testDataViewGetUint16: 889 ms. testDataViewGetInt32: 888 ms. testDataViewGetFloat64: 890 ms. meaning we lost around 10% on the single byte case, but gained 10% across the board for all the other element sizes. Design-Document: http://bit.ly/turbofan-word64 Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383 Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83 Reviewed-on: https://chromium-review.googlesource.com/c/1303732Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
-
- 24 Oct, 2018 2 commits
-
-
Benedikt Meurer authored
This changes the ReceiverOrOddball feedback on JSStrictEqual to ReceiverOrNullOrUndefined feedback, which can also safely be consumed by JSEqual (we cannot generally accept any oddball here since booleans trigger implicit conversions, unfortunately). Thus we replace the previously introduced CheckReceiverOrOddball with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since we will no longer collect Oddball feedback separately. TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into a sequence like this: ``` left = CheckReceiverOrNullOrUndefined(left); right = CheckReceiverOrNullOrUndefined(right); result = if ObjectIsUndetectable(left) then ObjectIsUndetectable(right) else ReferenceEqual(left, right); ``` This significantly improves the peak performance of abstract equality with Receiver, Null or Undefined inputs. On the test case outlined in http://crbug.com/v8/8356 we go from naive: 2946 ms. tenary: 2134 ms. to naive: 2230 ms. tenary: 2250 ms. which corresponds to a 25% improvement on the abstract equality case. For regular code this will probably yield more performance, since we get rid of the JSEqual operator, which might have arbitrary side effects and thus blocks all kinds of TurboFan optimizations. The JSStrictEqual case is slightly slower now, since it has to rule out booleans as well (even though that's not strictly necessary, but consistency is key here). This way developers can safely use `a == b` instead of doing a dance like `a == null ? b == null : a === b` (which is what dart2js does right now) when both `a` and `b` are known to be Receiver, Null or Undefined. The abstract equality is not only faster to parse than the tenary, but also generates a shorter bytecode sequence. In the test case referenced in http://crbug.com/v8/8356 the bytecode for `naive` is ``` StackCheck Ldar a1 TestEqual a0, [0] JumpIfFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 14 bytes, whereas the `tenary` function generates ``` StackCheck Ldar a0 TestUndetectable JumpIfFalse [7] Ldar a1 TestUndetectable Jump [7] Ldar a1 TestEqualStrict a0, [0] JumpIfToBooleanFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 24 bytes. So the `naive` version is 40% smaller and requires fewer bytecode dispatches. Bug: chromium:898455, v8:8356 Change-Id: If3961b2518b4438700706b3bd6071d546305e233 Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56948}
-
Benedikt Meurer authored
This CL introduces proper Oddball and ReceiverOrOddball states for the CompareOperationFeedback, and updates the StrictEqual IC to collect this feedback as well. Previously it would not collect Oddball feedback, not even in the sense of NumberOrOddball, since that's not usable for the SpeculativeNumberEqual. The new feedback is handled via newly introduced CheckReceiverOrOddball and CheckOddball operators in TurboFan, introduced by JSTypedLowering. Just like with the Receiver feedback, it's enough to check one side and do a ReferenceEqual afterwards, since strict equal can only yield true if both sides refer to the same instance. This improves the benchmark mentioned in http://crbug.com/v8/8356 from naive: 2950 ms. tenary: 2456 ms. to around naive: 2996 ms. tenary: 2192 ms. which corresponds to a roughly 10% improvement in the case for the tenary pattern, which is currently used by dart2js. In real world scenarios this will probably help even more, since TurboFan is able to optimize across the strict equality, i.e. there's no longer a stub call forcibly spilling all registers that are live across the call. This new feedback will be used as a basis for the JSEqual support for ReceiverOrOddball, which will allow dart2js switching to the shorter a==b form, at the same peak performance. Bug: v8:8356 Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2 Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56925}
-
- 07 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This reverts commit 4fd92b25. Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots) Original change's description: > [turbofan] Do not consume SignedSmall feedback in TurboFan anymore. > > This changes TurboFan to treat SignedSmall feedback similar to Signed32 > feedback for binary and compare operations, in order to simplify and > unify the machinery. > > This is an experiment. If this turns out to tank performance, we will > need to revisit and ideally revert this change. > > Bug: v8:7094 > Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 > Reviewed-on: https://chromium-review.googlesource.com/c/1261442 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56411} TBR=jarin@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7094 Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404 Reviewed-on: https://chromium-review.googlesource.com/c/1267175Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56427}
-
- 05 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This changes TurboFan to treat SignedSmall feedback similar to Signed32 feedback for binary and compare operations, in order to simplify and unify the machinery. This is an experiment. If this turns out to tank performance, we will need to revisit and ideally revert this change. Bug: v8:7094 Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1 Reviewed-on: https://chromium-review.googlesource.com/c/1261442Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56411}
-
- 04 Oct, 2018 1 commit
-
-
Jaroslav Sevcik authored
The goal is to remove CL to remove the confusing implications for full poisoning. This is an alternative to https://chromium-review.googlesource.com/c/chromium/src/+/1253341 where chrome has to work around our implication system. In the optimizing compiler, we already have a bottleneck for setting mitigation level in src/compiler/pipeline.cc, so it is easy to change back to partial mitigations. Bug: chromium:888892 Change-Id: I01de7ed7bb91e8b06f8f79cc2d90657a0600892a Reviewed-on: https://chromium-review.googlesource.com/c/1252985Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56374}
-
- 17 Sep, 2018 2 commits
-
-
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}
-
Benedikt Meurer authored
This change introduces the necessary conversion operators to convert from Word64 to other representations (Tagged, Word32, Float64, etc.), and plugs in the Word64 representation for NumberAdd/NumberSubtract, such that TurboFan will go to Int64Add/Sub on 64-bit architectures when the inputs and the output of the operation is in safe integer range. This includes the necessary changes to the Deoptimizer to be able to rematerialize Int64 values as Smi/HeapNumber when going back to Ignition later. This change might affect performance, although measurements indicate that there should be no noticable performance impact. The goal is to have TurboFan support Word64 representation to a degree that changing the TypedArray length to an uint64_t (for 64-bit archs) becomes viable and doesn't have any negative performance implications. Independent of that we might get performance improvements in other areas such as for crypto code later. Bug: v8:4153, v8:7881, v8:8171, v8:8178 Design-Document: bit.ly/turbofan-word64 Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel Reviewed-on: https://chromium-review.googlesource.com/1225709 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55937}
-
- 14 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This adds support to TurboFan's representation selection for the Word64 representation, and makes use of that to handle indices for memory access and allocation instructions (i.e. LoadElement, StoreElement, Allocate, etc.). These instructions had previously used Word32 as representation for the indices / sizes, and then internally converted it to the correct representation (aka Word64 on 64-bit architectures) later on, but that was kind of brittle, and sometimes led to weird generated code. The change thus only adds support to convert integer values in the safe integer range from all kinds of representations to Word64 (on 64-bit architectures). We don't yet handle the opposite direction and none of the representation selection heuristics for the numeric operations were changed so far. This will be done in follow-up CLs. This CL itself is supposed to be neutral wrt. functionality, and only serves as a starting point, and a cleanup for the (weird) implicit Word64 index/size handling. Bug: v8:7881, v8:8015, v8:8171 Design-Document: http://bit.ly/turbofan-word64 Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel Reviewed-on: https://chromium-review.googlesource.com/1224932 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55886}
-
- 07 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
This replaces the previous CheckStringAdd operator which deopts in case the combined length overflows with a dedicated pure StringConcat operator. This operator is similar to NewConsString in that it takes the resulting length plus the two input strings. The operator relies on the length being checked explicitly by the surrounding code instead of baking the check into the operator itself. This way TurboFan can eliminate redundant/unnecessary StringConcat operations, since they are pure now. This also unifies the treatment of string addition in JSTypedLowering, and generalizes the StringLength constant-folding to apply to more cases not just the JSAdd cases inside JSTypedLowering. Bug: v8:7902, v8:8015 Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f Reviewed-on: https://chromium-review.googlesource.com/1213205Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55725}
-
- 29 Aug, 2018 1 commit
-
-
Maya Lekova authored
The new node is introduced for literal string addition and calling String.prototype.concat in the typed lowering phase. It later might get optimized away during redundancy elimination, keeping the performance of already existing benchmarks with string addition. In case the operation is about to throw (due to too long string being constructed) we just deoptimize, reusing the interpreter logic for creating the error. Modify relevant mjsunit and unit tests for string concatenation. Bug: v8:7902 Change-Id: Ie97d39534df4480fa8d4fe3ba276d02ed5e750e3 Reviewed-on: https://chromium-review.googlesource.com/1193342 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#55482}
-
- 22 Aug, 2018 1 commit
-
-
Benedikt Meurer authored
This adds the missing support for HOLEY_DOUBLE_ELEMENTS to both `Array#find()` and `Array#findIndex()`. The implementation just deopts whenever it hits a double hole. In order to prevent deoptimization loops we add feedback to the CheckFloat64Hole operator, which also addresses the TODO in the `%ArrayIteratorPrototype%.next()` lowering. This provides a speed-up of up to 8x in microbenchmarks when using `Array#find()` or `Array#findIndex()` on HOLEY_DOUBLE_ELEMENTS arrays. Bug: chromium:791045, v8:1956, v8:6587, v8:7165, v8:8015 Change-Id: I1be22d3fcba56c676a81dc31a9042f8123ef3a55 Reviewed-on: https://chromium-review.googlesource.com/1183906Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55321}
-
- 09 Jul, 2018 1 commit
-
-
Théotime Grohens authored
This CL completes the implementation of DataView prototype methods in TurboFan, by implementing the Uint8, Int8, Uint16, Int16, Uint32, Int32, Float32 and Float64 setters. DataView performance is now ahead of the equivalent TypedArray wrapper, and is now expected to at least match TypedArray performance in the general case as well. This CL also adds a test file in the compiler directory, to make sure that the setters actually behave correctly. Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8 Reviewed-on: https://chromium-review.googlesource.com/1128867Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Théotime Grohens <theotime@google.com> Cr-Commit-Position: refs/heads/master@{#54331}
-
- 05 Jul, 2018 1 commit
-
-
Théotime Grohens authored
This CL adds a Reduction for the DataViewGetInt16 and -Uint16 builtins, and the corresponding handling in LoadDataViewElement node in the effect control linearizer. It also adds tests for the new getters. Change-Id: I5101755e47657c25f10be1417f105e3ae72a3c39 Reviewed-on: https://chromium-review.googlesource.com/1126919 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54271}
-
- 04 Jul, 2018 1 commit
-
-
Théotime Grohens authored
This CL creates a new Operator called LoadDataViewElement, similar to LoadTypedArray, for DataView getters. This operator will be used as a wrapper around all the computations that DataViews need to do when loading values, due to the endianness parameter of DataView loads. Change-Id: Ie67d63c9669142e539a5c8d7ae82dc1018ce5858 Reviewed-on: https://chromium-review.googlesource.com/1125928 Commit-Queue: Théotime Grohens <theotime@google.com> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54217}
-
- 29 May, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7779 Change-Id: I97d7a46039d9063e4169fa215f7f6857c80eb3b9 Reviewed-on: https://chromium-review.googlesource.com/1076087Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#53404}
-