2018-05-13 10:10:44 +00:00
|
|
|
// Copyright 2015 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 <cmath>
|
|
|
|
|
|
2019-05-17 12:13:44 +00:00
|
|
|
#include "src/api/api-inl.h"
|
2018-05-13 10:10:44 +00:00
|
|
|
#include "src/base/utils/random-number-generator.h"
|
|
|
|
|
#include "src/builtins/builtins-promise-gen.h"
|
|
|
|
|
#include "src/builtins/builtins-string-gen.h"
|
2019-05-21 09:30:15 +00:00
|
|
|
#include "src/codegen/code-factory.h"
|
|
|
|
|
#include "src/codegen/code-stub-assembler.h"
|
2018-05-13 10:10:44 +00:00
|
|
|
#include "src/compiler/node.h"
|
|
|
|
|
#include "src/debug/debug.h"
|
2019-05-22 07:55:37 +00:00
|
|
|
#include "src/execution/isolate.h"
|
2019-05-20 08:54:18 +00:00
|
|
|
#include "src/objects/elements-kind.h"
|
2019-05-23 08:51:46 +00:00
|
|
|
#include "src/objects/objects-inl.h"
|
2018-05-13 10:10:44 +00:00
|
|
|
#include "src/objects/promise-inl.h"
|
2019-05-21 06:38:38 +00:00
|
|
|
#include "src/strings/char-predicates.h"
|
2018-05-13 10:10:44 +00:00
|
|
|
#include "test/cctest/compiler/code-assembler-tester.h"
|
|
|
|
|
#include "test/cctest/compiler/function-tester.h"
|
|
|
|
|
|
|
|
|
|
namespace v8 {
|
|
|
|
|
namespace internal {
|
|
|
|
|
namespace compiler {
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
2019-05-27 11:31:49 +00:00
|
|
|
using Label = CodeAssemblerLabel;
|
|
|
|
|
using Variable = CodeAssemblerVariable;
|
2018-05-13 10:10:44 +00:00
|
|
|
|
2019-05-27 19:25:38 +00:00
|
|
|
class TestTorqueAssembler : public CodeStubAssembler {
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
public:
|
|
|
|
|
explicit TestTorqueAssembler(CodeAssemblerState* state)
|
2019-05-27 19:25:38 +00:00
|
|
|
: CodeStubAssembler(state) {}
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
};
|
|
|
|
|
|
2018-05-13 10:10:44 +00:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
|
|
TEST(TestConstexpr1) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 10:10:44 +00:00
|
|
|
{
|
|
|
|
|
m.TestConstexpr1();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-05-22 12:48:29 +00:00
|
|
|
ft.Call();
|
2018-05-13 10:10:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestConstexprIf) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 10:10:44 +00:00
|
|
|
{
|
|
|
|
|
m.TestConstexprIf();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-05-22 12:48:29 +00:00
|
|
|
ft.Call();
|
2018-05-13 10:10:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestConstexprReturn) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 10:10:44 +00:00
|
|
|
{
|
|
|
|
|
m.TestConstexprReturn();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-05-22 12:48:29 +00:00
|
|
|
ft.Call();
|
2018-05-13 10:10:44 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-13 14:24:08 +00:00
|
|
|
TEST(TestGotoLabel) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 14:24:08 +00:00
|
|
|
{ m.Return(m.TestGotoLabel()); }
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestGotoLabelWithOneParameter) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 14:24:08 +00:00
|
|
|
{ m.Return(m.TestGotoLabelWithOneParameter()); }
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestGotoLabelWithTwoParameters) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-13 14:24:08 +00:00
|
|
|
{ m.Return(m.TestGotoLabelWithTwoParameters()); }
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-14 10:53:04 +00:00
|
|
|
TEST(TestPartiallyUnusedLabel) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-14 10:53:04 +00:00
|
|
|
{ m.Return(m.TestPartiallyUnusedLabel()); }
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-16 09:45:07 +00:00
|
|
|
TEST(TestBuiltinSpecialization) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-16 09:45:07 +00:00
|
|
|
{
|
|
|
|
|
Node* temp = m.SmiConstant(0);
|
|
|
|
|
m.TestBuiltinSpecialization(m.UncheckedCast<Context>(temp));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-05-22 12:48:29 +00:00
|
|
|
ft.Call();
|
2018-05-16 09:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestMacroSpecialization) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-16 09:45:07 +00:00
|
|
|
{
|
|
|
|
|
m.TestMacroSpecialization();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-05-22 12:48:29 +00:00
|
|
|
ft.Call();
|
2018-05-16 09:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-16 14:00:35 +00:00
|
|
|
TEST(TestFunctionPointers) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
const int kNumParams = 0;
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, kNumParams);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-16 14:00:35 +00:00
|
|
|
{
|
|
|
|
|
TNode<Context> context =
|
|
|
|
|
m.UncheckedCast<Context>(m.Parameter(kNumParams + 2));
|
|
|
|
|
m.Return(m.TestFunctionPointers(context));
|
|
|
|
|
}
|
2018-07-03 12:02:05 +00:00
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), kNumParams);
|
2018-05-16 14:00:35 +00:00
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-03 12:02:05 +00:00
|
|
|
TEST(TestTernaryOperator) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
const int kNumParams = 1;
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, kNumParams);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-07-03 12:02:05 +00:00
|
|
|
{
|
|
|
|
|
TNode<Smi> arg = m.UncheckedCast<Smi>(m.Parameter(0));
|
|
|
|
|
m.Return(m.TestTernaryOperator(arg));
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), kNumParams);
|
|
|
|
|
Handle<Object> result1 =
|
|
|
|
|
ft.Call(Handle<Smi>(Smi::FromInt(-5), isolate)).ToHandleChecked();
|
|
|
|
|
CHECK_EQ(-15, Handle<Smi>::cast(result1)->value());
|
|
|
|
|
Handle<Object> result2 =
|
|
|
|
|
ft.Call(Handle<Smi>(Smi::FromInt(3), isolate)).ToHandleChecked();
|
|
|
|
|
CHECK_EQ(103, Handle<Smi>::cast(result2)->value());
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-22 12:48:29 +00:00
|
|
|
TEST(TestFunctionPointerToGeneric) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-22 12:48:29 +00:00
|
|
|
{
|
|
|
|
|
Node* temp = m.SmiConstant(0);
|
|
|
|
|
m.TestFunctionPointerToGeneric(m.UncheckedCast<Context>(temp));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-29 14:18:39 +00:00
|
|
|
TEST(TestUnsafeCast) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-05-29 14:18:39 +00:00
|
|
|
{
|
|
|
|
|
Node* temp = m.SmiConstant(0);
|
|
|
|
|
Node* n = m.SmiConstant(10);
|
|
|
|
|
m.Return(m.TestUnsafeCast(m.UncheckedCast<Context>(temp),
|
|
|
|
|
m.UncheckedCast<Number>(n)));
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.CheckCall(ft.true_value());
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-05 08:49:05 +00:00
|
|
|
TEST(TestHexLiteral) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-06-05 08:49:05 +00:00
|
|
|
{
|
|
|
|
|
m.TestHexLiteral();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-13 08:50:22 +00:00
|
|
|
TEST(TestModuleConstBindings) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-07-13 08:50:22 +00:00
|
|
|
{
|
|
|
|
|
m.TestModuleConstBindings();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-17 06:39:07 +00:00
|
|
|
TEST(TestLocalConstBindings) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-07-17 06:39:07 +00:00
|
|
|
{
|
|
|
|
|
m.TestLocalConstBindings();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-27 10:32:14 +00:00
|
|
|
TEST(TestForLoop) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-07-27 10:32:14 +00:00
|
|
|
{
|
|
|
|
|
m.TestForLoop();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-07 21:57:19 +00:00
|
|
|
TEST(TestTypeswitch) {
|
2018-11-26 15:14:25 +00:00
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
2018-08-07 21:57:19 +00:00
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-08-07 21:57:19 +00:00
|
|
|
{
|
2018-11-26 15:14:25 +00:00
|
|
|
m.TestTypeswitch(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
2018-08-07 21:57:19 +00:00
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-07 14:06:18 +00:00
|
|
|
TEST(TestGenericOverload) {
|
2018-11-26 15:14:25 +00:00
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
2018-08-07 14:06:18 +00:00
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-08-07 14:06:18 +00:00
|
|
|
{
|
2018-11-26 15:14:25 +00:00
|
|
|
m.TestGenericOverload(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
2018-08-07 14:06:18 +00:00
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2019-02-06 15:17:35 +00:00
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestEquality) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestEquality(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
2018-08-07 14:06:18 +00:00
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
[torque] disallow using logical operators in value contexts
This CL makes sure, that logical operators (||, &&) always have return
type never. Together with a check that never is never passed as a
function argument, this prevents faulty evaluation as in !(x || y).
Before, the logical operators had a behavior similar to
(bool labels Taken, NotTaken), with a fast exit if the left-hand side
allowed shor-circuit evaluation, but returning the right-hand side
otherwise. Since we want to allow existing (a || b || c) patterns in
the codebase, this requires weakening the restriction that the left-
and right-hand side need to have the same type. Now the possibilites
are:
bool, never
never, bool
never, never
bool, bool
constexpr bool, constexpr bool
Bug: v8:8137
Change-Id: I9576b337dc4008ac58b4625e77fef4e73bcdd6e3
Reviewed-on: https://chromium-review.googlesource.com/1215162
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55750}
2018-09-08 16:16:08 +00:00
|
|
|
TEST(TestLogicalOperators) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
[torque] disallow using logical operators in value contexts
This CL makes sure, that logical operators (||, &&) always have return
type never. Together with a check that never is never passed as a
function argument, this prevents faulty evaluation as in !(x || y).
Before, the logical operators had a behavior similar to
(bool labels Taken, NotTaken), with a fast exit if the left-hand side
allowed shor-circuit evaluation, but returning the right-hand side
otherwise. Since we want to allow existing (a || b || c) patterns in
the codebase, this requires weakening the restriction that the left-
and right-hand side need to have the same type. Now the possibilites
are:
bool, never
never, bool
never, never
bool, bool
constexpr bool, constexpr bool
Bug: v8:8137
Change-Id: I9576b337dc4008ac58b4625e77fef4e73bcdd6e3
Reviewed-on: https://chromium-review.googlesource.com/1215162
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55750}
2018-09-08 16:16:08 +00:00
|
|
|
{
|
|
|
|
|
m.TestLogicalOperators();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-08 13:50:46 +00:00
|
|
|
TEST(TestOtherwiseAndLabels) {
|
|
|
|
|
Isolate* isolate(CcTest::InitIsolateOnce());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-10-08 13:50:46 +00:00
|
|
|
{
|
|
|
|
|
m.TestOtherwiseWithCode1();
|
|
|
|
|
m.TestOtherwiseWithCode2();
|
|
|
|
|
m.TestOtherwiseWithCode3();
|
|
|
|
|
m.TestForwardLabel();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-31 13:00:51 +00:00
|
|
|
TEST(TestCatch1) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-10-31 13:00:51 +00:00
|
|
|
{
|
|
|
|
|
TNode<Smi> result =
|
|
|
|
|
m.TestCatch1(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
USE(result);
|
|
|
|
|
CSA_ASSERT(&m, m.WordEqual(result, m.SmiConstant(1)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestCatch2) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-10-31 13:00:51 +00:00
|
|
|
{
|
|
|
|
|
TNode<Smi> result =
|
|
|
|
|
m.TestCatch2(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
USE(result);
|
|
|
|
|
CSA_ASSERT(&m, m.WordEqual(result, m.SmiConstant(2)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestCatch3) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-10-31 13:00:51 +00:00
|
|
|
{
|
|
|
|
|
TNode<Smi> result =
|
|
|
|
|
m.TestCatch3(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
USE(result);
|
|
|
|
|
CSA_ASSERT(&m, m.WordEqual(result, m.SmiConstant(2)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-02 12:40:31 +00:00
|
|
|
TEST(TestLookup) {
|
2018-11-26 15:14:25 +00:00
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
2018-11-02 12:40:31 +00:00
|
|
|
CodeAssemblerTester asm_tester(isolate, 0);
|
[torque] enable multiple inheritance from Torque-generated assemblers
This enables more seamless interop between Torque and CSA:
Since CodeStubAssembler can now inherit from the Torque base namespace,
macros defined in the base namespace can be used in CodeStubAssembler
macros, even without qualification.
At the same time, macros in the base namespace can refer to
CodeStubAssembler macros. The only new limitation is that types defined
in code-stub-assembler.h cannot be referenced in the signature of macros
defined in the base namespace, since this would produce a cyclic header
dependency. A work-around for this woud be to put such types (like int31
in this CL) into a separate header included by both. I (mis-)used
code-assembler.h for that.
Another side-effec is that types and enums defined in CodeStubAssembler
have to be accessed in a qualified way from Torque.
Other assemblers can now inherit from their Torque equivalent, so
porting macros into the corresponding Torque namespace doesn't require
any change to the existing use-sites.
To avoid C++ ambiguities, the Torque-generated assemblers must not define
anything also defined in Code(Stub)Assembler. This includes the type
aliases for TNode, PLabel, ...
My workaround is to qualify everything in the generated C++.
As a drive-by fix, I had to change the formatter to avoid a situation
where it doesn't compute a fixed point: putting a keyword at the
beginning of a line removes the '\s' in front of it, so I replaced that
with '\b'.
Bug: v8:7793
Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
Reviewed-on: https://chromium-review.googlesource.com/c/1341955
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57645}
2018-11-20 10:17:24 +00:00
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
2018-11-02 12:40:31 +00:00
|
|
|
{
|
2018-11-26 15:14:25 +00:00
|
|
|
m.TestQualifiedAccess(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
2018-11-02 12:40:31 +00:00
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2018-12-07 16:29:49 +00:00
|
|
|
TEST(TestFrame1) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestFrame1(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
[torque] Implement methods and constructors for structs and classes
With the changes in this patch, it is now possible to add methods to
both Torque's class and struct types. As a special case, "constructor"
methods are used to initialize the values of classes and structs when
they are constructed.
The functionality in this patch includes:
- The refactoring of class- and struct-handling code to share field
and method declaration code between both.
- Addition of the "%Allocate" intrinsic that allocates raw bytes to be
allocated from the V8 GC's NewSpace heap as the basis for freshly
created, initialized class objects.
- An implementation of a CallMethodExpression AST node that enables
calling methods and constructors, including special handling of
passing through the "this" pointer for method calls on structs by
reference. The syntax for struct construction using "{}" remains as
before, but now calls the struct's matching constructor rather than
implicitly initializing the struct fields with the initialization
arguments. A new syntax for allocation classes is introduced: "new
ClassName{constructor_param1, constructor_param1, ...}", which
de-sugars to an %Allocate call followed by a call to the matching
constructor.
- class constructors can use the "super" keyword to initialize their
super class.
- If classes and struct do not have a constructor, Torque creates a
default constructor for them based on their field declarations,
where each field's initial value is assigned to a same-typed
parameter to the the default constructor. The default constructor's
parameters are in field-declaration order, and for derived classes,
the default constructor automatically uses a "super" initialization
call to initialize inherited fields.
- Class field declarations now automatically create ".field" and
".field=" operators that create CSA-compatible object accessors.
- Addition of a no-argument constructor for JSArrays that creates an
empty, PACKED_SMI_ELEMENTS JSArray using the machinery added
elsewhere in this patch.
Bug: v8:7793
Change-Id: I31ce5f4b444656ab999555d780aeeba605666bfa
Reviewed-on: https://chromium-review.googlesource.com/c/1392192
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58860}
2019-01-16 16:25:29 +00:00
|
|
|
TEST(TestNew) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestNew(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestStructConstructor) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestStructConstructor(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-05 12:39:44 +00:00
|
|
|
TEST(TestInternalClass) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestInternalClass(m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-04 17:23:05 +00:00
|
|
|
TEST(TestNewFixedArrayFromSpread) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestNewFixedArrayFromSpread(
|
|
|
|
|
m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-11 13:36:05 +00:00
|
|
|
TEST(TestReferences) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestReferences();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-21 14:59:31 +00:00
|
|
|
TEST(TestStaticAssert) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestStaticAssert();
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
FunctionTester ft(asm_tester.GenerateCode(), 0);
|
|
|
|
|
ft.Call();
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-12 11:30:05 +00:00
|
|
|
TEST(TestLoadEliminationFixedNoWrite) {
|
2019-06-04 14:19:40 +00:00
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
2019-06-12 11:30:05 +00:00
|
|
|
m.TestLoadEliminationFixedNoWrite(
|
|
|
|
|
m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
asm_tester.GenerateCode();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TEST(TestLoadEliminationVariableNoWrite) {
|
|
|
|
|
CcTest::InitializeVM();
|
|
|
|
|
Isolate* isolate(CcTest::i_isolate());
|
|
|
|
|
i::HandleScope scope(isolate);
|
|
|
|
|
Handle<Context> context =
|
|
|
|
|
Utils::OpenHandle(*v8::Isolate::GetCurrent()->GetCurrentContext());
|
|
|
|
|
CodeAssemblerTester asm_tester(isolate);
|
|
|
|
|
TestTorqueAssembler m(asm_tester.state());
|
|
|
|
|
{
|
|
|
|
|
m.TestLoadEliminationVariableNoWrite(
|
2019-06-04 14:19:40 +00:00
|
|
|
m.UncheckedCast<Context>(m.HeapConstant(context)));
|
|
|
|
|
m.Return(m.UndefinedConstant());
|
|
|
|
|
}
|
|
|
|
|
asm_tester.GenerateCode();
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-13 10:10:44 +00:00
|
|
|
} // namespace compiler
|
|
|
|
|
} // namespace internal
|
|
|
|
|
} // namespace v8
|
