2014-07-30 13:54:45 +00:00
|
|
|
// Copyright 2014 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.
|
|
|
|
|
|
|
|
#include <limits>
|
|
|
|
|
2019-07-11 14:08:25 +00:00
|
|
|
#include "src/compiler/access-info.h"
|
|
|
|
#include "src/compiler/js-heap-broker.h"
|
2017-02-23 11:46:29 +00:00
|
|
|
#include "src/compiler/node-matchers.h"
|
|
|
|
#include "src/compiler/representation-change.h"
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
#include "src/compiler/type-cache.h"
|
2019-05-23 08:51:46 +00:00
|
|
|
#include "src/objects/objects-inl.h"
|
2014-07-30 13:54:45 +00:00
|
|
|
#include "test/cctest/cctest.h"
|
2015-01-30 09:29:25 +00:00
|
|
|
#include "test/cctest/compiler/codegen-tester.h"
|
2019-05-07 09:18:58 +00:00
|
|
|
#include "test/cctest/compiler/graph-and-builders.h"
|
2014-09-24 16:04:05 +00:00
|
|
|
#include "test/cctest/compiler/value-helper.h"
|
2014-07-30 13:54:45 +00:00
|
|
|
|
2015-10-30 09:16:26 +00:00
|
|
|
namespace v8 {
|
2014-07-30 13:54:45 +00:00
|
|
|
namespace internal {
|
|
|
|
namespace compiler {
|
|
|
|
|
|
|
|
class RepresentationChangerTester : public HandleAndZoneScope,
|
|
|
|
public GraphAndBuilders {
|
|
|
|
public:
|
2014-08-05 08:47:39 +00:00
|
|
|
explicit RepresentationChangerTester(int num_parameters = 0)
|
2020-07-23 10:06:02 +00:00
|
|
|
: HandleAndZoneScope(kCompressGraphZone),
|
|
|
|
GraphAndBuilders(main_zone()),
|
2014-09-12 11:06:37 +00:00
|
|
|
javascript_(main_zone()),
|
2015-01-23 15:19:34 +00:00
|
|
|
jsgraph_(main_isolate(), main_graph_, &main_common_, &javascript_,
|
2015-10-26 14:29:15 +00:00
|
|
|
&main_simplified_, &main_machine_),
|
2020-08-12 14:39:53 +00:00
|
|
|
broker_(main_isolate(), main_zone()),
|
2019-07-11 14:08:25 +00:00
|
|
|
changer_(&jsgraph_, &broker_) {
|
2014-08-05 08:47:39 +00:00
|
|
|
Node* s = graph()->NewNode(common()->Start(num_parameters));
|
|
|
|
graph()->SetStart(s);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2014-09-12 11:06:37 +00:00
|
|
|
JSOperatorBuilder javascript_;
|
2014-07-30 13:54:45 +00:00
|
|
|
JSGraph jsgraph_;
|
2019-07-11 14:08:25 +00:00
|
|
|
JSHeapBroker broker_;
|
2014-07-30 13:54:45 +00:00
|
|
|
RepresentationChanger changer_;
|
|
|
|
|
|
|
|
Isolate* isolate() { return main_isolate(); }
|
|
|
|
Graph* graph() { return main_graph_; }
|
|
|
|
CommonOperatorBuilder* common() { return &main_common_; }
|
|
|
|
JSGraph* jsgraph() { return &jsgraph_; }
|
|
|
|
RepresentationChanger* changer() { return &changer_; }
|
|
|
|
|
|
|
|
// TODO(titzer): use ValueChecker / ValueUtil
|
|
|
|
void CheckInt32Constant(Node* n, int32_t expected) {
|
2014-09-08 09:16:11 +00:00
|
|
|
Int32Matcher m(n);
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_EQ(expected, m.ResolvedValue());
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
void CheckInt64Constant(Node* n, int64_t expected) {
|
|
|
|
Int64Matcher m(n);
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_EQ(expected, m.ResolvedValue());
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
}
|
|
|
|
|
2014-09-24 16:04:05 +00:00
|
|
|
void CheckUint32Constant(Node* n, uint32_t expected) {
|
|
|
|
Uint32Matcher m(n);
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_EQ(static_cast<int>(expected), static_cast<int>(m.ResolvedValue()));
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void CheckFloat64Constant(Node* n, double expected) {
|
|
|
|
Float64Matcher m(n);
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_DOUBLE_EQ(expected, m.ResolvedValue());
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void CheckFloat32Constant(Node* n, float expected) {
|
|
|
|
CHECK_EQ(IrOpcode::kFloat32Constant, n->opcode());
|
|
|
|
float fval = OpParameter<float>(n->op());
|
2016-03-07 12:29:06 +00:00
|
|
|
CHECK_FLOAT_EQ(expected, fval);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
2018-12-20 15:47:47 +00:00
|
|
|
void CheckHeapConstant(Node* n, HeapObject expected) {
|
2015-06-19 12:48:58 +00:00
|
|
|
HeapObjectMatcher m(n);
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_EQ(expected, *m.ResolvedValue());
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void CheckNumberConstant(Node* n, double expected) {
|
2014-09-08 09:16:11 +00:00
|
|
|
NumberMatcher m(n);
|
2014-07-30 13:54:45 +00:00
|
|
|
CHECK_EQ(IrOpcode::kNumberConstant, n->opcode());
|
2020-10-28 15:48:08 +00:00
|
|
|
CHECK(m.HasResolvedValue());
|
|
|
|
CHECK_DOUBLE_EQ(expected, m.ResolvedValue());
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2015-01-14 12:06:41 +00:00
|
|
|
Node* Parameter(int index = 0) {
|
2015-11-18 10:02:12 +00:00
|
|
|
Node* n = graph()->NewNode(common()->Parameter(index), graph()->start());
|
|
|
|
NodeProperties::SetType(n, Type::Any());
|
|
|
|
return n;
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* Return(Node* input) {
|
2016-11-02 13:15:39 +00:00
|
|
|
Node* n = graph()->NewNode(common()->Return(), jsgraph()->Int32Constant(0),
|
|
|
|
input, graph()->start(), graph()->start());
|
2016-06-02 09:20:50 +00:00
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
2018-04-27 11:55:34 +00:00
|
|
|
void CheckTypeError(MachineRepresentation from, Type from_type,
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation to) {
|
2014-07-30 13:54:45 +00:00
|
|
|
changer()->testing_type_errors_ = true;
|
|
|
|
changer()->type_error_ = false;
|
|
|
|
Node* n = Parameter(0);
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* use = Return(n);
|
|
|
|
Node* c = changer()->GetRepresentationFor(n, from, from_type, use,
|
|
|
|
UseInfo(to, Truncation::None()));
|
2014-07-30 13:54:45 +00:00
|
|
|
CHECK(changer()->type_error_);
|
2014-08-14 09:19:54 +00:00
|
|
|
CHECK_EQ(n, c);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2018-04-27 11:55:34 +00:00
|
|
|
void CheckNop(MachineRepresentation from, Type from_type,
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation to) {
|
2014-07-30 13:54:45 +00:00
|
|
|
Node* n = Parameter(0);
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* use = Return(n);
|
|
|
|
Node* c = changer()->GetRepresentationFor(n, from, from_type, use,
|
|
|
|
UseInfo(to, Truncation::None()));
|
2014-07-30 13:54:45 +00:00
|
|
|
CHECK_EQ(n, c);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-12-10 09:03:30 +00:00
|
|
|
const MachineType kMachineTypes[] = {
|
2019-11-11 11:36:04 +00:00
|
|
|
MachineType::Float32(), MachineType::Float64(), MachineType::Int8(),
|
|
|
|
MachineType::Uint8(), MachineType::Int16(), MachineType::Uint16(),
|
|
|
|
MachineType::Int32(), MachineType::Uint32(), MachineType::Int64(),
|
|
|
|
MachineType::Uint64(), MachineType::AnyTagged()};
|
2014-07-30 13:54:45 +00:00
|
|
|
|
2015-01-14 12:06:41 +00:00
|
|
|
TEST(BoolToBit_constant) {
|
2014-07-30 13:54:45 +00:00
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
|
|
|
Node* true_node = r.jsgraph()->TrueConstant();
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* true_use = r.Return(true_node);
|
2015-12-10 09:03:30 +00:00
|
|
|
Node* true_bit = r.changer()->GetRepresentationFor(
|
2016-06-02 09:20:50 +00:00
|
|
|
true_node, MachineRepresentation::kTagged, Type::None(), true_use,
|
|
|
|
UseInfo(MachineRepresentation::kBit, Truncation::None()));
|
2014-07-30 13:54:45 +00:00
|
|
|
r.CheckInt32Constant(true_bit, 1);
|
|
|
|
|
|
|
|
Node* false_node = r.jsgraph()->FalseConstant();
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* false_use = r.Return(false_node);
|
2015-12-10 09:03:30 +00:00
|
|
|
Node* false_bit = r.changer()->GetRepresentationFor(
|
2016-06-02 09:20:50 +00:00
|
|
|
false_node, MachineRepresentation::kTagged, Type::None(), false_use,
|
|
|
|
UseInfo(MachineRepresentation::kBit, Truncation::None()));
|
2014-07-30 13:54:45 +00:00
|
|
|
r.CheckInt32Constant(false_bit, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(ToTagged_constant) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (double i : ValueHelper::float64_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kFloat64, Type::None(), use,
|
|
|
|
UseInfo(MachineRepresentation::kTagged, Truncation::None()));
|
|
|
|
r.CheckNumberConstant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (int i : ValueHelper::int32_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Signed32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kTagged, Truncation::None()));
|
|
|
|
r.CheckNumberConstant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (uint32_t i : ValueHelper::uint32_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Unsigned32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kTagged, Truncation::None()));
|
|
|
|
r.CheckNumberConstant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(ToFloat64_constant) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (double i : ValueHelper::float64_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kTagged, Type::None(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat64, Truncation::None()));
|
|
|
|
r.CheckFloat64Constant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (int i : ValueHelper::int32_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Signed32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat64, Truncation::None()));
|
|
|
|
r.CheckFloat64Constant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (uint32_t i : ValueHelper::uint32_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Unsigned32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat64, Truncation::None()));
|
|
|
|
r.CheckFloat64Constant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
2018-11-19 13:10:19 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
Node* n = r.jsgraph()->Constant(0);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord64, Type::Range(0, 0, r.zone()), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat64, Truncation::None()));
|
|
|
|
r.CheckFloat64Constant(c, 0);
|
|
|
|
}
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static bool IsFloat32Int32(int32_t val) {
|
|
|
|
return val >= -(1 << 23) && val <= (1 << 23);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static bool IsFloat32Uint32(uint32_t val) { return val <= (1 << 23); }
|
|
|
|
|
|
|
|
|
|
|
|
TEST(ToFloat32_constant) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2016-10-19 12:05:15 +00:00
|
|
|
for (double i : ValueHelper::float32_vector()) {
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kTagged, Type::None(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat32, Truncation::None()));
|
|
|
|
r.CheckFloat32Constant(c, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (int i : ValueHelper::int32_vector()) {
|
|
|
|
if (!IsFloat32Int32(i)) continue;
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Signed32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat32, Truncation::None()));
|
|
|
|
r.CheckFloat32Constant(c, static_cast<float>(i));
|
|
|
|
}
|
|
|
|
|
|
|
|
for (uint32_t i : ValueHelper::uint32_vector()) {
|
|
|
|
if (!IsFloat32Uint32(i)) continue;
|
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kWord32, Type::Unsigned32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kFloat32, Truncation::None()));
|
|
|
|
r.CheckFloat32Constant(c, static_cast<float>(i));
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(ToInt32_constant) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
{
|
|
|
|
FOR_INT32_INPUTS(i) {
|
2019-02-01 10:37:04 +00:00
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* use = r.Return(n);
|
2015-12-10 09:03:30 +00:00
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
2016-06-02 09:20:50 +00:00
|
|
|
n, MachineRepresentation::kTagged, Type::Signed32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kWord32, Truncation::None()));
|
2019-02-01 10:37:04 +00:00
|
|
|
r.CheckInt32Constant(c, i);
|
2014-09-24 16:04:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST(ToUint32_constant) {
|
|
|
|
RepresentationChangerTester r;
|
2016-10-19 12:05:15 +00:00
|
|
|
FOR_UINT32_INPUTS(i) {
|
2019-02-01 10:37:04 +00:00
|
|
|
Node* n = r.jsgraph()->Constant(static_cast<double>(i));
|
2016-10-19 12:05:15 +00:00
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
|
|
|
n, MachineRepresentation::kTagged, Type::Unsigned32(), use,
|
|
|
|
UseInfo(MachineRepresentation::kWord32, Truncation::None()));
|
2019-02-01 10:37:04 +00:00
|
|
|
r.CheckUint32Constant(c, i);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
TEST(ToInt64_constant) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
FOR_INT32_INPUTS(i) {
|
2019-02-01 10:37:04 +00:00
|
|
|
Node* n = r.jsgraph()->Constant(i);
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c = r.changer()->GetRepresentationFor(
|
2019-01-02 14:50:17 +00:00
|
|
|
n, MachineRepresentation::kTagged, TypeCache::Get()->kSafeInteger, use,
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
UseInfo(MachineRepresentation::kWord64, Truncation::None()));
|
2019-02-01 10:37:04 +00:00
|
|
|
r.CheckInt64Constant(c, i);
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-12 05:54:24 +00:00
|
|
|
static void CheckChange(IrOpcode::Value expected, MachineRepresentation from,
|
2018-04-27 11:55:34 +00:00
|
|
|
Type from_type, UseInfo use_info) {
|
2014-07-30 13:54:45 +00:00
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2015-01-14 12:06:41 +00:00
|
|
|
Node* n = r.Parameter();
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* use = r.Return(n);
|
2016-10-12 09:53:13 +00:00
|
|
|
Node* c =
|
|
|
|
r.changer()->GetRepresentationFor(n, from, from_type, use, use_info);
|
2014-07-30 13:54:45 +00:00
|
|
|
|
|
|
|
CHECK_NE(c, n);
|
|
|
|
CHECK_EQ(expected, c->opcode());
|
|
|
|
CHECK_EQ(n, c->InputAt(0));
|
2016-10-12 09:53:13 +00:00
|
|
|
|
[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
|
|
|
if (expected == IrOpcode::kCheckedFloat64ToInt32 ||
|
|
|
|
expected == IrOpcode::kCheckedFloat64ToInt64) {
|
2016-10-12 09:53:13 +00:00
|
|
|
CheckForMinusZeroMode mode =
|
2018-04-30 08:58:25 +00:00
|
|
|
from_type.Maybe(Type::MinusZero())
|
2016-10-12 09:53:13 +00:00
|
|
|
? use_info.minus_zero_check()
|
|
|
|
: CheckForMinusZeroMode::kDontCheckForMinusZero;
|
2017-12-18 11:36:47 +00:00
|
|
|
CHECK_EQ(mode, CheckMinusZeroParametersOf(c->op()).mode());
|
2016-10-12 09:53:13 +00:00
|
|
|
}
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2016-10-12 09:53:13 +00:00
|
|
|
static void CheckChange(IrOpcode::Value expected, MachineRepresentation from,
|
2018-04-27 11:55:34 +00:00
|
|
|
Type from_type, MachineRepresentation to) {
|
2018-10-03 10:37:08 +00:00
|
|
|
CheckChange(expected, from, from_type, UseInfo(to, Truncation::Any()));
|
2016-10-12 09:53:13 +00:00
|
|
|
}
|
2014-07-30 13:54:45 +00:00
|
|
|
|
2014-09-24 11:55:07 +00:00
|
|
|
static void CheckTwoChanges(IrOpcode::Value expected2,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::Value expected1,
|
2018-04-27 11:55:34 +00:00
|
|
|
MachineRepresentation from, Type from_type,
|
[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
|
|
|
MachineRepresentation to, UseInfo use_info) {
|
2014-09-24 11:55:07 +00:00
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2015-01-14 12:06:41 +00:00
|
|
|
Node* n = r.Parameter();
|
2016-06-02 09:20:50 +00:00
|
|
|
Node* use = r.Return(n);
|
[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
|
|
|
Node* c1 =
|
|
|
|
r.changer()->GetRepresentationFor(n, from, from_type, use, use_info);
|
2014-09-24 11:55:07 +00:00
|
|
|
|
|
|
|
CHECK_NE(c1, n);
|
|
|
|
CHECK_EQ(expected1, c1->opcode());
|
|
|
|
Node* c2 = c1->InputAt(0);
|
|
|
|
CHECK_NE(c2, n);
|
|
|
|
CHECK_EQ(expected2, c2->opcode());
|
|
|
|
CHECK_EQ(n, c2->InputAt(0));
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
static void CheckTwoChanges(IrOpcode::Value expected2,
|
|
|
|
IrOpcode::Value expected1,
|
|
|
|
MachineRepresentation from, Type from_type,
|
|
|
|
MachineRepresentation to) {
|
|
|
|
CheckTwoChanges(expected2, expected1, from, from_type, to,
|
|
|
|
UseInfo(to, Truncation::None()));
|
|
|
|
}
|
|
|
|
|
2016-07-27 11:38:15 +00:00
|
|
|
static void CheckChange(IrOpcode::Value expected, MachineRepresentation from,
|
2018-04-27 11:55:34 +00:00
|
|
|
Type from_type, MachineRepresentation to,
|
2016-07-27 11:38:15 +00:00
|
|
|
UseInfo use_info) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
|
|
|
Node* n = r.Parameter();
|
|
|
|
Node* use = r.Return(n);
|
|
|
|
Node* c =
|
|
|
|
r.changer()->GetRepresentationFor(n, from, from_type, use, use_info);
|
|
|
|
|
|
|
|
CHECK_NE(c, n);
|
|
|
|
CHECK_EQ(expected, c->opcode());
|
|
|
|
CHECK_EQ(n, c->InputAt(0));
|
|
|
|
}
|
2014-09-24 11:55:07 +00:00
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
TEST(Word64) {
|
2018-09-18 08:09:27 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToInt64, MachineRepresentation::kWord8,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kInt8, MachineRepresentation::kWord64);
|
2018-09-18 08:09:27 +00:00
|
|
|
CheckChange(IrOpcode::kChangeUint32ToUint64, MachineRepresentation::kWord8,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kUint8, MachineRepresentation::kWord64);
|
2018-09-18 08:09:27 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToInt64, MachineRepresentation::kWord16,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kInt16, MachineRepresentation::kWord64);
|
2018-09-18 08:09:27 +00:00
|
|
|
CheckChange(IrOpcode::kChangeUint32ToUint64, MachineRepresentation::kWord16,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kUint16, MachineRepresentation::kWord64);
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToInt64, MachineRepresentation::kWord32,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord64);
|
2019-06-18 10:37:18 +00:00
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kChangeInt32ToInt64, MachineRepresentation::kWord32,
|
|
|
|
Type::Signed32OrMinusZero(), MachineRepresentation::kWord64,
|
|
|
|
UseInfo(MachineRepresentation::kWord64, Truncation::Any(kIdentifyZeros)));
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeUint32ToUint64, MachineRepresentation::kWord32,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord64);
|
2019-06-18 10:37:18 +00:00
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kChangeUint32ToUint64, MachineRepresentation::kWord32,
|
|
|
|
Type::Unsigned32OrMinusZero(), MachineRepresentation::kWord64,
|
|
|
|
UseInfo(MachineRepresentation::kWord64, Truncation::Any(kIdentifyZeros)));
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckChange(IrOpcode::kTruncateInt64ToInt32, MachineRepresentation::kWord64,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kTruncateInt64ToInt32, MachineRepresentation::kWord64,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kTruncateInt64ToInt32, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kWord32,
|
2018-09-14 15:28:42 +00:00
|
|
|
UseInfo::TruncatingWord32());
|
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedInt64ToInt32, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kWord32,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned32AsWord32(kIdentifyZeros, FeedbackSource()));
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedUint64ToInt32, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kPositiveSafeInteger, MachineRepresentation::kWord32,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned32AsWord32(kIdentifyZeros, FeedbackSource()));
|
2018-09-14 15:28:42 +00:00
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt64, MachineRepresentation::kFloat64,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord64);
|
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt64, MachineRepresentation::kFloat64,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord64);
|
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt64, MachineRepresentation::kFloat64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kWord64);
|
2018-09-18 18:06:25 +00:00
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt64, MachineRepresentation::kFloat64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kInt64, MachineRepresentation::kWord64);
|
2018-09-18 18:06:25 +00:00
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToUint64, MachineRepresentation::kFloat64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kUint64, MachineRepresentation::kWord64);
|
[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
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedFloat64ToInt64, MachineRepresentation::kFloat64,
|
|
|
|
Type::Number(), MachineRepresentation::kWord64,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned64AsWord64(kIdentifyZeros, FeedbackSource()));
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt64ToFloat64, MachineRepresentation::kWord64,
|
|
|
|
Type::Signed32(), MachineRepresentation::kFloat64);
|
|
|
|
CheckChange(IrOpcode::kChangeInt64ToFloat64, MachineRepresentation::kWord64,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kFloat64);
|
|
|
|
CheckChange(IrOpcode::kChangeInt64ToFloat64, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kFloat64);
|
2018-09-14 15:28:42 +00:00
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToInt64,
|
|
|
|
MachineRepresentation::kFloat32, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord64);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToInt64,
|
|
|
|
MachineRepresentation::kFloat32, Type::Unsigned32(),
|
|
|
|
MachineRepresentation::kWord64);
|
2018-09-18 18:06:25 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToInt64,
|
2019-01-02 14:50:17 +00:00
|
|
|
MachineRepresentation::kFloat32, TypeCache::Get()->kInt64,
|
2018-09-18 18:06:25 +00:00
|
|
|
MachineRepresentation::kWord64);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToUint64,
|
2019-01-02 14:50:17 +00:00
|
|
|
MachineRepresentation::kFloat32, TypeCache::Get()->kUint64,
|
2018-09-18 18:06:25 +00:00
|
|
|
MachineRepresentation::kWord64);
|
[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
|
|
|
CheckTwoChanges(
|
|
|
|
IrOpcode::kChangeFloat32ToFloat64, IrOpcode::kCheckedFloat64ToInt64,
|
|
|
|
MachineRepresentation::kFloat32, Type::Number(),
|
|
|
|
MachineRepresentation::kWord64,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned64AsWord64(kIdentifyZeros, FeedbackSource()));
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeInt64ToFloat64,
|
|
|
|
IrOpcode::kTruncateFloat64ToFloat32,
|
|
|
|
MachineRepresentation::kWord64, Type::Signed32(),
|
|
|
|
MachineRepresentation::kFloat32);
|
|
|
|
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt64, MachineRepresentation::kTagged,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord64);
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt64, MachineRepresentation::kTagged,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord64);
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt64, MachineRepresentation::kTagged,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kWord64);
|
2018-09-18 18:06:25 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt64, MachineRepresentation::kTagged,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kInt64, MachineRepresentation::kWord64);
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedSignedToInt64,
|
|
|
|
MachineRepresentation::kTaggedSigned, Type::SignedSmall(),
|
|
|
|
MachineRepresentation::kWord64);
|
[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
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedTaggedToInt64, MachineRepresentation::kTagged,
|
|
|
|
Type::Number(), MachineRepresentation::kWord64,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned64AsWord64(kIdentifyZeros, FeedbackSource()));
|
[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
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedTaggedToInt64, MachineRepresentation::kTaggedPointer,
|
|
|
|
Type::Number(), MachineRepresentation::kWord64,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned64AsWord64(kIdentifyZeros, FeedbackSource()));
|
2018-09-14 15:28:42 +00:00
|
|
|
|
|
|
|
CheckTwoChanges(IrOpcode::kTruncateInt64ToInt32,
|
|
|
|
IrOpcode::kChangeInt31ToTaggedSigned,
|
|
|
|
MachineRepresentation::kWord64, Type::Signed31(),
|
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
CheckTwoChanges(IrOpcode::kTruncateInt64ToInt32,
|
|
|
|
IrOpcode::kChangeInt32ToTagged,
|
|
|
|
MachineRepresentation::kWord64, Type::Signed32(),
|
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
CheckTwoChanges(IrOpcode::kTruncateInt64ToInt32,
|
|
|
|
IrOpcode::kChangeUint32ToTagged,
|
|
|
|
MachineRepresentation::kWord64, Type::Unsigned32(),
|
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
CheckChange(IrOpcode::kChangeInt64ToTagged, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kSafeInteger, MachineRepresentation::kTagged);
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckChange(IrOpcode::kChangeUint64ToTagged, MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kPositiveSafeInteger,
|
2018-09-14 15:28:42 +00:00
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
|
|
|
|
CheckTwoChanges(IrOpcode::kTruncateInt64ToInt32,
|
|
|
|
IrOpcode::kChangeInt31ToTaggedSigned,
|
|
|
|
MachineRepresentation::kWord64, Type::Signed31(),
|
|
|
|
MachineRepresentation::kTaggedSigned);
|
|
|
|
if (SmiValuesAre32Bits()) {
|
|
|
|
CheckTwoChanges(IrOpcode::kTruncateInt64ToInt32,
|
|
|
|
IrOpcode::kChangeInt32ToTagged,
|
|
|
|
MachineRepresentation::kWord64, Type::Signed32(),
|
|
|
|
MachineRepresentation::kTaggedSigned);
|
|
|
|
}
|
|
|
|
CheckChange(IrOpcode::kCheckedInt64ToTaggedSigned,
|
2019-01-02 14:50:17 +00:00
|
|
|
MachineRepresentation::kWord64, TypeCache::Get()->kSafeInteger,
|
2018-09-14 15:28:42 +00:00
|
|
|
MachineRepresentation::kTaggedSigned,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSignedSmallAsTaggedSigned(FeedbackSource()));
|
2018-09-14 15:28:42 +00:00
|
|
|
CheckChange(IrOpcode::kCheckedUint64ToTaggedSigned,
|
|
|
|
MachineRepresentation::kWord64,
|
2019-01-02 14:50:17 +00:00
|
|
|
TypeCache::Get()->kPositiveSafeInteger,
|
2018-09-14 15:28:42 +00:00
|
|
|
MachineRepresentation::kTaggedSigned,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSignedSmallAsTaggedSigned(FeedbackSource()));
|
2018-09-14 15:28:42 +00:00
|
|
|
|
2019-01-02 14:50:17 +00:00
|
|
|
CheckTwoChanges(
|
|
|
|
IrOpcode::kChangeInt64ToFloat64, IrOpcode::kChangeFloat64ToTaggedPointer,
|
|
|
|
MachineRepresentation::kWord64, TypeCache::Get()->kSafeInteger,
|
|
|
|
MachineRepresentation::kTaggedPointer);
|
[turbofan] Initial Word64 support in representation selection.
This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.
The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.
This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.
Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
2018-09-14 07:32:02 +00:00
|
|
|
}
|
|
|
|
|
2014-07-30 13:54:45 +00:00
|
|
|
TEST(SingleChanges) {
|
2016-05-02 10:23:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedToBit, MachineRepresentation::kTagged,
|
2016-08-25 16:57:31 +00:00
|
|
|
Type::Boolean(), MachineRepresentation::kBit);
|
2016-05-02 10:23:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeBitToTagged, MachineRepresentation::kBit,
|
2016-08-25 16:57:31 +00:00
|
|
|
Type::Boolean(), MachineRepresentation::kTagged);
|
2016-01-12 05:54:24 +00:00
|
|
|
|
2016-05-02 10:23:02 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt31ToTaggedSigned,
|
|
|
|
MachineRepresentation::kWord32, Type::Signed31(),
|
|
|
|
MachineRepresentation::kTagged);
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToTagged, MachineRepresentation::kWord32,
|
|
|
|
Type::Signed32(), MachineRepresentation::kTagged);
|
|
|
|
CheckChange(IrOpcode::kChangeUint32ToTagged, MachineRepresentation::kWord32,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kTagged);
|
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToTagged, MachineRepresentation::kFloat64,
|
2016-04-22 08:39:30 +00:00
|
|
|
Type::Number(), MachineRepresentation::kTagged);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat64ToInt32,
|
2016-05-02 10:23:02 +00:00
|
|
|
IrOpcode::kChangeInt31ToTaggedSigned,
|
2016-04-22 08:39:30 +00:00
|
|
|
MachineRepresentation::kFloat64, Type::Signed31(),
|
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat64ToInt32,
|
|
|
|
IrOpcode::kChangeInt32ToTagged,
|
|
|
|
MachineRepresentation::kFloat64, Type::Signed32(),
|
|
|
|
MachineRepresentation::kTagged);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat64ToUint32,
|
|
|
|
IrOpcode::kChangeUint32ToTagged,
|
|
|
|
MachineRepresentation::kFloat64, Type::Unsigned32(),
|
|
|
|
MachineRepresentation::kTagged);
|
2016-01-12 05:54:24 +00:00
|
|
|
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt32, MachineRepresentation::kTagged,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToUint32, MachineRepresentation::kTagged,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToFloat64, MachineRepresentation::kTagged,
|
2016-04-22 11:02:56 +00:00
|
|
|
Type::Number(), MachineRepresentation::kFloat64);
|
2016-05-31 11:59:59 +00:00
|
|
|
CheckChange(IrOpcode::kTruncateTaggedToFloat64,
|
|
|
|
MachineRepresentation::kTagged, Type::NumberOrUndefined(),
|
2019-05-31 06:28:19 +00:00
|
|
|
UseInfo(MachineRepresentation::kFloat64,
|
|
|
|
Truncation::OddballAndBigIntToNumber()));
|
2016-09-22 10:33:01 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedToFloat64, MachineRepresentation::kTagged,
|
|
|
|
Type::Signed31(), MachineRepresentation::kFloat64);
|
2014-07-30 13:54:45 +00:00
|
|
|
|
|
|
|
// Int32,Uint32 <-> Float64 are actually machine conversions.
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToFloat64, MachineRepresentation::kWord32,
|
|
|
|
Type::Signed32(), MachineRepresentation::kFloat64);
|
2018-10-03 10:37:08 +00:00
|
|
|
CheckChange(IrOpcode::kChangeInt32ToFloat64, MachineRepresentation::kWord32,
|
|
|
|
Type::Signed32OrMinusZero(), MachineRepresentation::kFloat64,
|
|
|
|
UseInfo(MachineRepresentation::kFloat64,
|
|
|
|
Truncation::Any(kIdentifyZeros)));
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckChange(IrOpcode::kChangeUint32ToFloat64, MachineRepresentation::kWord32,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kFloat64);
|
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt32, MachineRepresentation::kFloat64,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToUint32, MachineRepresentation::kFloat64,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord32);
|
|
|
|
|
|
|
|
CheckChange(IrOpcode::kTruncateFloat64ToFloat32,
|
2016-08-25 16:57:31 +00:00
|
|
|
MachineRepresentation::kFloat64, Type::Number(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
2014-10-08 11:16:45 +00:00
|
|
|
|
2014-09-24 11:55:07 +00:00
|
|
|
// Int32,Uint32 <-> Float32 require two changes.
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeInt32ToFloat64,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::kTruncateFloat64ToFloat32,
|
|
|
|
MachineRepresentation::kWord32, Type::Signed32(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
2014-09-24 11:55:07 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeUint32ToFloat64,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::kTruncateFloat64ToFloat32,
|
|
|
|
MachineRepresentation::kWord32, Type::Unsigned32(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToInt32,
|
|
|
|
MachineRepresentation::kFloat32, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord32);
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
|
|
|
IrOpcode::kChangeFloat64ToUint32,
|
|
|
|
MachineRepresentation::kFloat32, Type::Unsigned32(),
|
|
|
|
MachineRepresentation::kWord32);
|
2014-09-24 11:55:07 +00:00
|
|
|
|
|
|
|
// Float32 <-> Tagged require two changes.
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::kChangeFloat64ToTagged,
|
2016-08-25 16:57:31 +00:00
|
|
|
MachineRepresentation::kFloat32, Type::Number(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kTagged);
|
2014-09-24 11:55:07 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeTaggedToFloat64,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::kTruncateFloat64ToFloat32,
|
2016-08-25 16:57:31 +00:00
|
|
|
MachineRepresentation::kTagged, Type::Number(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
TEST(SignednessInWord32) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckChange(IrOpcode::kChangeTaggedToInt32, MachineRepresentation::kTagged,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kChangeTaggedToUint32, MachineRepresentation::kTagged,
|
|
|
|
Type::Unsigned32(), MachineRepresentation::kWord32);
|
|
|
|
CheckChange(IrOpcode::kChangeInt32ToFloat64, MachineRepresentation::kWord32,
|
2016-08-25 16:57:31 +00:00
|
|
|
Type::Signed32(), MachineRepresentation::kFloat64);
|
2016-01-12 05:54:24 +00:00
|
|
|
CheckChange(IrOpcode::kChangeFloat64ToInt32, MachineRepresentation::kFloat64,
|
|
|
|
Type::Signed32(), MachineRepresentation::kWord32);
|
2016-04-24 11:39:31 +00:00
|
|
|
CheckChange(IrOpcode::kTruncateFloat64ToWord32,
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kFloat64, Type::Number(),
|
2018-10-03 10:37:08 +00:00
|
|
|
MachineRepresentation::kWord32,
|
|
|
|
UseInfo(MachineRepresentation::kWord32, Truncation::Word32()));
|
2016-07-27 11:38:15 +00:00
|
|
|
CheckChange(IrOpcode::kCheckedTruncateTaggedToWord32,
|
2016-12-05 11:56:52 +00:00
|
|
|
MachineRepresentation::kTagged, Type::NonInternal(),
|
2016-07-27 11:38:15 +00:00
|
|
|
MachineRepresentation::kWord32,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedNumberOrOddballAsWord32(FeedbackSource()));
|
2014-09-24 11:55:07 +00:00
|
|
|
|
|
|
|
CheckTwoChanges(IrOpcode::kChangeInt32ToFloat64,
|
2016-01-12 05:54:24 +00:00
|
|
|
IrOpcode::kTruncateFloat64ToFloat32,
|
2016-08-25 16:57:31 +00:00
|
|
|
MachineRepresentation::kWord32, Type::Signed32(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
2014-09-24 11:55:07 +00:00
|
|
|
CheckTwoChanges(IrOpcode::kChangeFloat32ToFloat64,
|
2016-04-24 11:39:31 +00:00
|
|
|
IrOpcode::kTruncateFloat64ToWord32,
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kFloat32, Type::Number(),
|
2015-12-10 09:03:30 +00:00
|
|
|
MachineRepresentation::kWord32);
|
2018-11-06 13:55:53 +00:00
|
|
|
|
|
|
|
CheckChange(
|
|
|
|
IrOpcode::kCheckedUint32ToInt32, MachineRepresentation::kWord32,
|
|
|
|
Type::Unsigned32(),
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned32AsWord32(kIdentifyZeros, FeedbackSource()));
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2018-04-27 11:55:34 +00:00
|
|
|
static void TestMinusZeroCheck(IrOpcode::Value expected, Type from_type) {
|
2016-10-12 09:53:13 +00:00
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2017-12-18 11:36:47 +00:00
|
|
|
CheckChange(
|
|
|
|
expected, MachineRepresentation::kFloat64, from_type,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSignedSmallAsWord32(kDistinguishZeros, FeedbackSource()));
|
2016-10-12 09:53:13 +00:00
|
|
|
|
2017-12-18 11:36:47 +00:00
|
|
|
CheckChange(
|
|
|
|
expected, MachineRepresentation::kFloat64, from_type,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSignedSmallAsWord32(kIdentifyZeros, FeedbackSource()));
|
2016-10-12 09:53:13 +00:00
|
|
|
|
2018-01-22 16:13:50 +00:00
|
|
|
CheckChange(
|
|
|
|
expected, MachineRepresentation::kFloat64, from_type,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned32AsWord32(kDistinguishZeros, FeedbackSource()));
|
2016-10-12 09:53:13 +00:00
|
|
|
|
2018-01-22 16:13:50 +00:00
|
|
|
CheckChange(
|
|
|
|
expected, MachineRepresentation::kFloat64, from_type,
|
2019-08-26 07:28:22 +00:00
|
|
|
UseInfo::CheckedSigned32AsWord32(kDistinguishZeros, FeedbackSource()));
|
2016-10-12 09:53:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST(MinusZeroCheck) {
|
|
|
|
TestMinusZeroCheck(IrOpcode::kCheckedFloat64ToInt32, Type::NumberOrOddball());
|
|
|
|
// PlainNumber cannot be minus zero so the minus zero check should be
|
|
|
|
// eliminated.
|
|
|
|
TestMinusZeroCheck(IrOpcode::kCheckedFloat64ToInt32, Type::PlainNumber());
|
|
|
|
}
|
2014-07-30 13:54:45 +00:00
|
|
|
|
|
|
|
TEST(Nops) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
|
|
|
// X -> X is always a nop for any single representation X.
|
2015-12-10 09:03:30 +00:00
|
|
|
for (size_t i = 0; i < arraysize(kMachineTypes); i++) {
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckNop(kMachineTypes[i].representation(), Type::Number(),
|
2016-01-12 05:54:24 +00:00
|
|
|
kMachineTypes[i].representation());
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
2014-09-19 09:56:12 +00:00
|
|
|
// 32-bit floats.
|
2016-01-12 05:54:24 +00:00
|
|
|
r.CheckNop(MachineRepresentation::kFloat32, Type::Number(),
|
|
|
|
MachineRepresentation::kFloat32);
|
2014-09-19 09:56:12 +00:00
|
|
|
|
2014-08-14 09:19:54 +00:00
|
|
|
// 32-bit words can be used as smaller word sizes and vice versa, because
|
|
|
|
// loads from memory implicitly sign or zero extend the value to the
|
|
|
|
// full machine word size, and stores implicitly truncate.
|
2016-01-12 05:54:24 +00:00
|
|
|
r.CheckNop(MachineRepresentation::kWord32, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord8);
|
|
|
|
r.CheckNop(MachineRepresentation::kWord32, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord16);
|
|
|
|
r.CheckNop(MachineRepresentation::kWord32, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord32);
|
|
|
|
r.CheckNop(MachineRepresentation::kWord8, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord32);
|
|
|
|
r.CheckNop(MachineRepresentation::kWord16, Type::Signed32(),
|
|
|
|
MachineRepresentation::kWord32);
|
2014-08-14 09:19:54 +00:00
|
|
|
|
|
|
|
// kRepBit (result of comparison) is implicitly a wordish thing.
|
2016-01-12 05:54:24 +00:00
|
|
|
r.CheckNop(MachineRepresentation::kBit, Type::Boolean(),
|
|
|
|
MachineRepresentation::kWord8);
|
|
|
|
r.CheckNop(MachineRepresentation::kBit, Type::Boolean(),
|
|
|
|
MachineRepresentation::kWord16);
|
|
|
|
r.CheckNop(MachineRepresentation::kBit, Type::Boolean(),
|
|
|
|
MachineRepresentation::kWord32);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
TEST(TypeErrors) {
|
|
|
|
RepresentationChangerTester r;
|
|
|
|
|
2014-09-19 09:56:12 +00:00
|
|
|
// Floats cannot be implicitly converted to/from comparison conditions.
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckTypeError(MachineRepresentation::kBit, Type::Number(),
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kFloat32);
|
|
|
|
r.CheckTypeError(MachineRepresentation::kBit, Type::Boolean(),
|
|
|
|
MachineRepresentation::kFloat32);
|
2014-09-19 09:56:12 +00:00
|
|
|
|
2014-07-30 13:54:45 +00:00
|
|
|
// Word64 is internal and shouldn't be implicitly converted.
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckTypeError(MachineRepresentation::kWord64, Type::Internal(),
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kTagged);
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckTypeError(MachineRepresentation::kTagged, Type::Number(),
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kWord64);
|
|
|
|
r.CheckTypeError(MachineRepresentation::kTagged, Type::Boolean(),
|
|
|
|
MachineRepresentation::kWord64);
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckTypeError(MachineRepresentation::kWord64, Type::Internal(),
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kWord32);
|
2016-08-25 16:57:31 +00:00
|
|
|
r.CheckTypeError(MachineRepresentation::kWord32, Type::Number(),
|
2016-01-12 05:54:24 +00:00
|
|
|
MachineRepresentation::kWord64);
|
2014-07-30 13:54:45 +00:00
|
|
|
}
|
2015-10-30 09:16:26 +00:00
|
|
|
|
|
|
|
} // namespace compiler
|
|
|
|
} // namespace internal
|
|
|
|
} // namespace v8
|