v8/test/mjsunit/compiler/load-elimination-const-field.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

167 lines
5.2 KiB
JavaScript
Raw Normal View History

// Copyright 2019 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// Flags: --allow-natives-syntax
// Check that load elimination on const-marked fields works
(function() {
function maybe_sideeffect(b) { return 42; }
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
%NeverOptimizeFunction(maybe_sideeffect);
class B {
constructor(x) {
this.value = x;
}
}
%EnsureFeedbackVectorForFunction(B);
function lit_const_smi() {
let b = { value: 123 };
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, 123));
}
%PrepareFunctionForOptimization(lit_const_smi);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
lit_const_smi(); lit_const_smi();
%OptimizeFunctionOnNextCall(lit_const_smi); lit_const_smi();
function lit_const_object() {
let o = {x: 123};
let b = { value: o };
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, o));
}
%PrepareFunctionForOptimization(lit_const_object);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
lit_const_object(); lit_const_object();
%OptimizeFunctionOnNextCall(lit_const_object); lit_const_object();
function lit_computed_smi(k) {
let kk = 2 * k;
let b = { value: kk };
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, kk));
}
%PrepareFunctionForOptimization(lit_computed_smi);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
lit_computed_smi(1); lit_computed_smi(2);
%OptimizeFunctionOnNextCall(lit_computed_smi); lit_computed_smi(3);
// TODO(bmeurer): Fix const tracking for double fields in object literals
// lit_computed_smi(1.1); lit_computed_smi(2.2);
// %OptimizeFunctionOnNextCall(lit_computed_smi); lit_computed_smi(3.3);
function lit_param_object(k) {
let b = { value: k };
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, k));
}
%PrepareFunctionForOptimization(lit_param_object);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
lit_param_object({x: 1}); lit_param_object({x: 2});
%OptimizeFunctionOnNextCall(lit_param_object); lit_param_object({x: 3});
function nested_lit_param(k) {
let b = { x: { value: k } };
maybe_sideeffect(b);
let v1 = b.x.value;
maybe_sideeffect(b);
let v2 = b.x.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, k));
}
%PrepareFunctionForOptimization(nested_lit_param);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
nested_lit_param(1); nested_lit_param(2);
%OptimizeFunctionOnNextCall(nested_lit_param); nested_lit_param(3);
// TODO(bmeurer): Fix const tracking for double fields in object literals
// nested_lit_param(1.1); nested_lit_param(2.2);
// %OptimizeFunctionOnNextCall(nested_lit_param); nested_lit_param(3.3);
function nested_lit_param_object(k) {
let b = { x: { value: k } };
maybe_sideeffect(b);
let v1 = b.x.value;
maybe_sideeffect(b);
let v2 = b.x.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, k));
}
%PrepareFunctionForOptimization(nested_lit_param_object);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
nested_lit_param_object({x: 1}); nested_lit_param_object({x: 2});
%OptimizeFunctionOnNextCall(nested_lit_param_object);
nested_lit_param_object({x: 3});
function inst_param(k) {
let b = new B(k);
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, k));
}
%EnsureFeedbackVectorForFunction(B);
%PrepareFunctionForOptimization(inst_param);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
inst_param(1); inst_param(2);
%OptimizeFunctionOnNextCall(inst_param); inst_param(3);
// TODO(gsps): Reenable once we fully support const field information
// tracking in the presence of pointer compression.
// inst_param(1.1); inst_param(2.2);
// %OptimizeFunctionOnNextCall(inst_param); inst_param(3.3);
%PrepareFunctionForOptimization(inst_param);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
inst_param({x: 1}); inst_param({x: 2});
%OptimizeFunctionOnNextCall(inst_param); inst_param({x: 3});
function inst_computed(k) {
let kk = 2 * k;
let b = new B(kk);
maybe_sideeffect(b);
let v1 = b.value;
maybe_sideeffect(b);
let v2 = b.value;
%TurbofanStaticAssert(Object.is(v1, v2));
%TurbofanStaticAssert(Object.is(v2, kk));
}
%EnsureFeedbackVectorForFunction(B);
%PrepareFunctionForOptimization(inst_computed);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
inst_computed(1); inst_computed(2);
%OptimizeFunctionOnNextCall(inst_computed); inst_computed(3);
%PrepareFunctionForOptimization(inst_computed);
Reland "Make LoadElimination aware of const fields (Part 2; stores)" This is a reland of e588ff10e5d63e33758960cbd66f5950930b9266 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/+/1630676 Reviewed-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}
2019-05-27 07:41:41 +00:00
inst_computed(1.1); inst_computed(2.2);
%OptimizeFunctionOnNextCall(inst_computed); inst_computed(3.3);
})();