v8/test/mjsunit/compiler/redundancy-elimination.js

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

205 lines
5.3 KiB
JavaScript
Raw Normal View History

// Copyright 2018 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.
[turbofan] Eliminate redundant Smi checks around array accesses. As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
2018-09-26 14:47:25 +00:00
// Flags: --allow-natives-syntax --opt
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeNumberAdd with
// Number feedback.
(function() {
function bar(i) {
return ++i;
}
bar(0.1);
function foo(a, i) {
const x = a[i];
const y = a[bar(i)];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 0));
assertEquals(3, foo([1, 2], 0));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 0));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeNumberAdd with
// NumberOrOddball feedback.
(function() {
function bar(i) {
return ++i;
}
assertEquals(NaN, bar(undefined));
function foo(a, i) {
const x = a[i];
const y = a[bar(i)];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 0));
assertEquals(3, foo([1, 2], 0));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 0));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeNumberSubtract with
// Number feedback.
(function() {
function bar(i) {
return --i;
}
assertEquals(-0.9, bar(0.1));
function foo(a, i) {
const x = a[i];
const y = a[bar(i)];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 1));
assertEquals(3, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 1));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeNumberSubtract with
// NumberOrOddball feedback.
(function() {
function bar(i) {
return --i;
}
assertEquals(NaN, bar(undefined));
function foo(a, i) {
const x = a[i];
const y = a[bar(i)];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 1));
assertEquals(3, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 1));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeToNumber.
(function() {
function foo(a, i) {
const x = a[i];
const y = i++;
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 0));
%OptimizeFunctionOnNextCall(foo);
assertEquals(1, foo([1, 2], 0));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeSafeIntegerAdd.
(function() {
function foo(a, i) {
const x = a[i];
const y = a[++i];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 0));
assertEquals(3, foo([1, 2], 0));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 0));
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberOperation()
// TurboFan optimization for the case of SpeculativeSafeIntegerSubtract.
(function() {
function foo(a, i) {
const x = a[i];
const y = a[--i];
return x + y;
}
%PrepareFunctionForOptimization(foo);
assertEquals(3, foo([1, 2], 1));
assertEquals(3, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([1, 2], 1));
})();
[turbofan] Eliminate redundant Smi checks around array accesses. As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
2018-09-26 14:47:25 +00:00
// Test the RedundancyElimination::ReduceSpeculativeNumberComparison()
// TurboFan optimization for the case of SpeculativeNumberEqual.
(function() {
function foo(a, i) {
const x = a[i];
if (i === 0) return x;
return i;
}
%PrepareFunctionForOptimization(foo);
[turbofan] Eliminate redundant Smi checks around array accesses. As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
2018-09-26 14:47:25 +00:00
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
// Even passing -0 should not deoptimize and
// of course still pass the equality test above.
assertEquals(9, foo([9, 2], -0));
assertOptimized(foo);
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberComparison()
// TurboFan optimization for the case of SpeculativeNumberLessThan.
(function() {
function foo(a, i) {
const x = a[i];
if (i < 1) return x;
return i;
}
%PrepareFunctionForOptimization(foo);
[turbofan] Eliminate redundant Smi checks around array accesses. As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
2018-09-26 14:47:25 +00:00
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
// Even passing -0 should not deoptimize and
// of course still pass the equality test above.
assertEquals(9, foo([9, 2], -0));
assertOptimized(foo);
})();
// Test the RedundancyElimination::ReduceSpeculativeNumberComparison()
// TurboFan optimization for the case of SpeculativeNumberLessThanOrEqual.
(function() {
function foo(a, i) {
const x = a[i];
if (i <= 0) return x;
return i;
}
%PrepareFunctionForOptimization(foo);
[turbofan] Eliminate redundant Smi checks around array accesses. As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
2018-09-26 14:47:25 +00:00
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
%OptimizeFunctionOnNextCall(foo);
assertEquals(1, foo([1, 2], 0));
assertEquals(1, foo([1, 2], 1));
// Even passing -0 should not deoptimize and
// of course still pass the equality test above.
assertEquals(9, foo([9, 2], -0));
assertOptimized(foo);
})();