v8/test/mjsunit/compiler/int64.js

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

140 lines
3.6 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.
// Flags: --allow-natives-syntax
// Test NumberAdd with PositiveSafeInteger -> PositiveSafeInteger (as Tagged).
(function() {
function foo(x) {
const i = x ? 0xFFFFFFFF : 0;
return i + 1;
}
%PrepareFunctionForOptimization(foo);
assertEquals(0x000000001, foo(false));
assertEquals(0x000000001, foo(false));
assertEquals(0x100000000, foo(true));
assertEquals(0x100000000, foo(true));
%OptimizeFunctionOnNextCall(foo);
assertEquals(0x000000001, foo(false));
assertEquals(0x100000000, foo(true));
})();
// Test NumberAdd with SafeInteger -> SafeInteger (as Tagged).
(function() {
function foo(x) {
const i = x ? 0xFFFFFFFF : -1;
return i + 1;
}
%PrepareFunctionForOptimization(foo);
assertEquals(0x000000000, foo(false));
assertEquals(0x000000000, foo(false));
assertEquals(0x100000000, foo(true));
assertEquals(0x100000000, foo(true));
%OptimizeFunctionOnNextCall(foo);
assertEquals(0x000000000, foo(false));
assertEquals(0x100000000, foo(true));
})();
// NumberAdd: Smi x Unsigned32 -> SafeInteger (as Float64).
(function() {
const a = new Float64Array(1);
function foo(o) {
a[0] = o.x + 0xFFFFFFFF;
return a[0];
}
%PrepareFunctionForOptimization(foo);
assertEquals(0x0FFFFFFFF, foo({x:0}));
assertEquals(0x100000000, foo({x:1}));
%OptimizeFunctionOnNextCall(foo);
assertEquals(0x100000000, foo({x:1}));
})();
// NumberAdd: Smi x Unsigned32 -> SafeInteger (as TaggedSigned).
(function() {
function foo(o) {
return {x: Math.floor((o.x + 11123456789) + -11123456788)}.x;
}
%PrepareFunctionForOptimization(foo);
assertEquals(1, foo({x:0}));
assertEquals(2, foo({x:1}));
%OptimizeFunctionOnNextCall(foo);
assertEquals(2, foo({x:1}));
})();
// NumberSubtract: Unsigned32 x Unsigned32 -> SafeInteger (as Word32).
(function() {
function foo(a, i) {
i = ((i >>> 0)) - 0xFFFFFFFF;
return a[i];
}
%PrepareFunctionForOptimization(foo);
assertEquals(1, foo([1], 0xFFFFFFFF));
assertEquals(2, foo([2], 0xFFFFFFFF));
%OptimizeFunctionOnNextCall(foo);
assertEquals(3, foo([3], 0xFFFFFFFF));
})();
// Test that the Deoptimizer can handle Word64 properly.
(function() {
function foo(b) {
const i = ((b >>> 0)) - 0xFFFFFFFF;
%DeoptimizeFunction(foo);
return i;
}
%PrepareFunctionForOptimization(foo);
assertEquals(0, foo(0xFFFFFFFF));
assertEquals(0, foo(0xFFFFFFFF));
%OptimizeFunctionOnNextCall(foo);
assertEquals(0, foo(0xFFFFFFFF));
})();
[turbofan] Add support for huge DataViews. 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/1303732 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
2018-10-29 14:16:51 +00:00
// Test checked Float32->Word64 conversions.
(function() {
function foo(dv, i) {
i = dv.getFloat32(i, true);
return dv.getInt8(i, true);
}
%PrepareFunctionForOptimization(foo);
[turbofan] Add support for huge DataViews. 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/1303732 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
2018-10-29 14:16:51 +00:00
const dv = new DataView(new ArrayBuffer(10));
dv.setFloat32(0, 8, true);
dv.setFloat32(4, 9, true);
dv.setInt8(8, 42);
dv.setInt8(9, 24);
assertEquals(42, foo(dv, 0));
assertEquals(24, foo(dv, 4));
%OptimizeFunctionOnNextCall(foo);
assertEquals(42, foo(dv, 0));
assertEquals(24, foo(dv, 4));
})();
// Test checked Float64->Word64 conversions.
(function() {
function foo(dv, i) {
i = dv.getFloat64(i, true);
return dv.getInt8(i, true);
}
%PrepareFunctionForOptimization(foo);
[turbofan] Add support for huge DataViews. 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/1303732 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57095}
2018-10-29 14:16:51 +00:00
const dv = new DataView(new ArrayBuffer(18));
dv.setFloat64(0, 16, true);
dv.setFloat64(8, 17, true);
dv.setInt8(16, 42);
dv.setInt8(17, 24);
assertEquals(42, foo(dv, 0));
assertEquals(24, foo(dv, 8));
%OptimizeFunctionOnNextCall(foo);
assertEquals(42, foo(dv, 0));
assertEquals(24, foo(dv, 8));
})();