v8/test/unittests/codegen/source-position-table-unittest.cc

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

98 lines
3.0 KiB
C++
Raw Normal View History

// Copyright 2016 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 "src/codegen/source-position-table.h"
#include "test/unittests/test-utils.h"
namespace v8 {
namespace internal {
namespace interpreter {
class SourcePositionTableTest : public TestWithIsolate {
public:
SourcePositionTableTest() : zone_(isolate()->allocator(), ZONE_NAME) {}
~SourcePositionTableTest() override = default;
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
2016-11-14 17:21:37 +00:00
SourcePosition toPos(int offset) {
return SourcePosition(offset, offset % 10 - 1);
}
SourcePositionTableBuilder* builder() { return &builder_; }
private:
Zone zone_;
SourcePositionTableBuilder builder_{&zone_};
};
// Some random offsets, mostly at 'suspicious' bit boundaries.
static int offsets[] = {0, 1, 2, 3, 4, 30, 31, 32,
33, 62, 63, 64, 65, 126, 127, 128,
129, 250, 1000, 9999, 12000, 31415926};
TEST_F(SourcePositionTableTest, EncodeStatement) {
for (size_t i = 0; i < arraysize(offsets); i++) {
builder()->AddPosition(offsets[i], toPos(offsets[i]), true);
}
// To test correctness, we rely on the assertions in ToSourcePositionTable().
// (Also below.)
CHECK(!builder()->ToSourcePositionTable(isolate()).is_null());
}
TEST_F(SourcePositionTableTest, EncodeStatementDuplicates) {
for (size_t i = 0; i < arraysize(offsets); i++) {
builder()->AddPosition(offsets[i], toPos(offsets[i]), true);
builder()->AddPosition(offsets[i], toPos(offsets[i] + 1), true);
}
// To test correctness, we rely on the assertions in ToSourcePositionTable().
// (Also below.)
CHECK(!builder()->ToSourcePositionTable(isolate()).is_null());
}
TEST_F(SourcePositionTableTest, EncodeExpression) {
for (size_t i = 0; i < arraysize(offsets); i++) {
builder()->AddPosition(offsets[i], toPos(offsets[i]), false);
}
CHECK(!builder()->ToSourcePositionTable(isolate()).is_null());
}
[backend] Fix source position annotations If two call instructions were generated right after each other, the source position table could get populated with two entries for the same PC (triggered by the follow-up CL: https://crrev.com/c/2697359). This CL fixes that by slightly changing the carry-over of source positions from nodes to instructions. The call node which has a source position attached generates two instructions: 18: gap () ([rax|R|tp] = v16(-); [rbx|R|t] = v17(-);) [rax|R|t] = ArchCallWasmFunction [immediate:4] #-1 [rax|R|tp] [rbx|R|t] [immediate:5] 19: gap () () ArchJmp [immediate:6] Those are then reversed, and the source position is attached to the first one (the ArchJmp). After reversing it again later, the source position will be set to the pc *after* the call instruction, which in the example happened to be just another call instruction which already had a source position, resulting in this code: [...] 0x388ee467d426 66 e875feffff call 0x388ee467d2a0 ;; wasm stub: WasmThrow 0x388ee467d42b 6b e850feffff call 0x388ee467d280 ;; wasm stub: WasmStackGuard [...] Source positions: pc offset position 6b 5 6b 0 By attaching the source position to the *last* instruction (after reversing), we ensure that it will be generated for an instruction *before* the call, or the call itself if this is the first instruction emitted for that node. R=jgruber@chromium.org Bug: v8:11490, v8:11496 Change-Id: Ie95c87d0d9daea56ca14a811abcd02ac07a4cf84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697358 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72951}
2021-02-23 11:33:27 +00:00
TEST_F(SourcePositionTableTest, EncodeAscendingPositive) {
int code_offset = 0;
int source_position = 0;
for (size_t i = 0; i < arraysize(offsets); i++) {
code_offset += offsets[i];
source_position += offsets[i];
if (i % 2) {
builder()->AddPosition(code_offset, toPos(source_position), true);
} else {
builder()->AddPosition(code_offset, toPos(source_position), false);
}
}
[backend] Fix source position annotations If two call instructions were generated right after each other, the source position table could get populated with two entries for the same PC (triggered by the follow-up CL: https://crrev.com/c/2697359). This CL fixes that by slightly changing the carry-over of source positions from nodes to instructions. The call node which has a source position attached generates two instructions: 18: gap () ([rax|R|tp] = v16(-); [rbx|R|t] = v17(-);) [rax|R|t] = ArchCallWasmFunction [immediate:4] #-1 [rax|R|tp] [rbx|R|t] [immediate:5] 19: gap () () ArchJmp [immediate:6] Those are then reversed, and the source position is attached to the first one (the ArchJmp). After reversing it again later, the source position will be set to the pc *after* the call instruction, which in the example happened to be just another call instruction which already had a source position, resulting in this code: [...] 0x388ee467d426 66 e875feffff call 0x388ee467d2a0 ;; wasm stub: WasmThrow 0x388ee467d42b 6b e850feffff call 0x388ee467d280 ;; wasm stub: WasmStackGuard [...] Source positions: pc offset position 6b 5 6b 0 By attaching the source position to the *last* instruction (after reversing), we ensure that it will be generated for an instruction *before* the call, or the call itself if this is the first instruction emitted for that node. R=jgruber@chromium.org Bug: v8:11490, v8:11496 Change-Id: Ie95c87d0d9daea56ca14a811abcd02ac07a4cf84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697358 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72951}
2021-02-23 11:33:27 +00:00
CHECK(!builder()->ToSourcePositionTable(isolate()).is_null());
}
TEST_F(SourcePositionTableTest, EncodeAscendingNegative) {
int code_offset = 0;
// Start with a big source position, then decrement it.
int source_position = 1 << 26;
for (size_t i = 0; i < arraysize(offsets); i++) {
code_offset += offsets[i];
source_position -= offsets[i];
if (i % 2) {
builder()->AddPosition(code_offset, toPos(source_position), true);
} else {
builder()->AddPosition(code_offset, toPos(source_position), false);
}
}
CHECK(!builder()->ToSourcePositionTable(isolate()).is_null());
}
} // namespace interpreter
} // namespace internal
} // namespace v8