v8/test/mjsunit/regress/regress-crbug-987205.js
Georg Schmid 7fd1922823 [turbofan] Relax double const store invariant in load elim. for literals
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/+/1763535
Reviewed-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}
2019-08-23 17:10:48 +00:00

69 lines
1.4 KiB
JavaScript

// 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
function f(x) {
// This used to generate two distinct stores to #undefined, violating the load
// elimination invariant that there are no two store to the same const field:
var obj1 = {
[undefined]: 1,
'undefined': 1
};
// This one cannot be discharged statically:
var obj2 = {
[undefined]: x,
'undefined': 1
};
// Some more variations that exercise AllocateFastLiteral:
var obj3 = {
'undefined': 1,
[undefined]: x
};
var obj4 = {
'undefined': x,
[undefined]: 1
};
assertEquals(obj1.undefined, 1);
assertEquals(obj2.undefined, 1);
assertEquals(obj3.undefined, x);
assertEquals(obj4.undefined, 1);
}
%PrepareFunctionForOptimization(f);
f(1);
f(1);
%OptimizeFunctionOnNextCall(f);
f(2);
function g(x) {
var obj1 = {
[undefined]: 1,
[undefined]: 1
};
var obj2 = {
[undefined]: 1,
[undefined]: x
};
var obj3 = {
[undefined]: x,
[undefined]: 1
};
var obj4 = {
[undefined]: x,
[undefined]: x
};
assertEquals(obj1.undefined, 1);
assertEquals(obj2.undefined, x);
assertEquals(obj3.undefined, 1);
assertEquals(obj4.undefined, x);
}
%PrepareFunctionForOptimization(g);
g(1);
g(1);
%OptimizeFunctionOnNextCall(g);
g(2);