2018-09-20 11:15:25 +00:00
|
|
|
// 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
|
2018-09-20 11:15:25 +00:00
|
|
|
|
|
|
|
|
// 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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%PrepareFunctionForOptimization(foo);
|
2018-09-20 11:15:25 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%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));
|
|
|
|
|
assertOptimized(foo);
|
2020-04-27 18:59:14 +00:00
|
|
|
assertEquals(9, foo([9, 2], -0));
|
[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 SpeculativeNumberLessThan.
|
|
|
|
|
(function() {
|
|
|
|
|
function foo(a, i) {
|
|
|
|
|
const x = a[i];
|
|
|
|
|
if (i < 1) return x;
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%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));
|
|
|
|
|
assertOptimized(foo);
|
2020-04-27 18:59:14 +00:00
|
|
|
assertEquals(9, foo([9, 2], -0));
|
[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 SpeculativeNumberLessThanOrEqual.
|
|
|
|
|
(function() {
|
|
|
|
|
function foo(a, i) {
|
|
|
|
|
const x = a[i];
|
|
|
|
|
if (i <= 0) return x;
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-01 10:19:54 +00:00
|
|
|
%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));
|
|
|
|
|
assertOptimized(foo);
|
2020-04-27 18:59:14 +00:00
|
|
|
assertEquals(9, foo([9, 2], -0));
|
[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
|
|
|
})();
|
