AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
3b4cc88e9c
v8/test/cctest/interpreter/bytecode-expectations-printer.h

113 lines
4.0 KiB
C
Raw Normal View History

[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
// 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.
#ifndef TEST_CCTEST_INTERPRETER_BYTECODE_EXPECTATIONS_PRINTER_H_
#define TEST_CCTEST_INTERPRETER_BYTECODE_EXPECTATIONS_PRINTER_H_
#include <iostream>
#include <string>
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
#include <vector>
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
#include "src/interpreter/bytecodes.h"
#include "src/objects.h"
namespace v8 {
class Isolate;
namespace internal {
Use source position table for unoptimized code. R=bmeurer@chromium.org, jgruber@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2095893002 Cr-Commit-Position: refs/heads/master@{#37309}
2016-06-28 05:51:09 +00:00
class SourcePositionTableIterator;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
namespace interpreter {
class BytecodeArrayIterator;
class BytecodeExpectationsPrinter final {
public:
[Interpreter] Remove constant pool type in tests For historical reasons, the interpreter's bytecode expectations tests required a type for the constant pool. This had two disadvantages: 1. Strings and numbers were not visible in mixed pools, and 2. Mismatches of pool types (e.g. when rebaselining) would cause parser errors This removes the pool types, making everything 'mixed', but appending the values to string and number valued constants. Specifying a pool type in the *.golden header now prints a warning (for backwards compatibility). BUG=v8:5350 Review-Url: https://codereview.chromium.org/2310103002 Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:10:19 +00:00
explicit BytecodeExpectationsPrinter(v8::Isolate* i)
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
: isolate_(i),
execute_(true),
wrap_(true),
[Interpreter] Refactor bytecode generator test suite. Bytecode expectations have been moved to external (.golden) files, one per test. Each test in the suite builds a representation of the the compiled bytecode using BytecodeExpectationsPrinter. The output is then compared to the golden file. If the comparision fails, a textual diff can be used to identify the discrepancies. Only the test snippets are left in the cc file, which also allows to make it more compact and meaningful. Leaving the snippets in the cc file was a deliberate choice to allow keeping the "truth" about the tests in the cc file, which will rarely change, as opposed to golden files. Golden files can be generated and kept up to date using generate-bytecode-expectations, which also means that the test suite can be batch updated whenever the bytecode or golden format changes. The golden format has been slightly amended (no more comments about `void*`, add size of the bytecode array) following the consideration made while converting the tests. There is also a fix: BytecodeExpectationsPrinter::top_level_ was left uninitialized, leading to undefined behaviour. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1717293002 Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:07 +00:00
top_level_(false),
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
test_function_name_(kDefaultTopFunctionName) {}
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
void PrintExpectation(std::ostream& stream, // NOLINT
const std::string& snippet) const;
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
void set_execute(bool execute) { execute_ = execute; }
bool execute() const { return execute_; }
void set_wrap(bool wrap) { wrap_ = wrap; }
bool wrap() const { return wrap_; }
void set_top_level(bool top_level) { top_level_ = top_level; }
bool top_level() const { return top_level_; }
void set_test_function_name(const std::string& test_function_name) {
test_function_name_ = test_function_name;
}
std::string test_function_name() const { return test_function_name_; }
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
private:
void PrintEscapedString(std::ostream& stream, // NOLINT
const std::string& string) const;
void PrintBytecodeOperand(std::ostream& stream, // NOLINT
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
const BytecodeArrayIterator& bytecode_iterator,
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
const Bytecode& bytecode, int op_index,
int parameter_count) const;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
void PrintBytecode(std::ostream& stream, // NOLINT
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
const BytecodeArrayIterator& bytecode_iterator,
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
int parameter_count) const;
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
void PrintSourcePosition(std::ostream& stream, // NOLINT
SourcePositionTableIterator& source_iterator,
int bytecode_offset) const;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
void PrintV8String(std::ostream& stream, // NOLINT
i::String* string) const;
void PrintConstant(std::ostream& stream, // NOLINT
i::Handle<i::Object> constant) const;
void PrintFrameSize(std::ostream& stream, // NOLINT
i::Handle<i::BytecodeArray> bytecode_array) const;
void PrintBytecodeSequence(std::ostream& stream, // NOLINT
i::Handle<i::BytecodeArray> bytecode_array) const;
void PrintConstantPool(std::ostream& stream, // NOLINT
i::FixedArray* constant_pool) const;
void PrintCodeSnippet(std::ostream& stream, // NOLINT
const std::string& body) const;
void PrintBytecodeArray(std::ostream& stream, // NOLINT
i::Handle<i::BytecodeArray> bytecode_array) const;
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
void PrintHandlers(std::ostream& stream, // NOLINT
i::Handle<i::BytecodeArray> bytecode_array) const;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
v8::Local<v8::String> V8StringFromUTF8(const char* data) const;
std::string WrapCodeInFunction(const char* function_name,
const std::string& function_body) const;
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
v8::Local<v8::Script> Compile(const char* program) const;
void Run(v8::Local<v8::Script> script) const;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
i::Handle<i::BytecodeArray> GetBytecodeArrayForGlobal(
const char* global_name) const;
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
i::Handle<v8::internal::BytecodeArray> GetBytecodeArrayForScript(
v8::Local<v8::Script> script) const;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
i::Isolate* i_isolate() const {
return reinterpret_cast<i::Isolate*>(isolate_);
}
v8::Isolate* isolate_;
[Interpreter] generate-bytecode-expectations improvements. A few options and features have been added to the tool: * an output file might be specified using --output=file.name * a shortcut when the output file is also the input, which is handy when fixing golden files, --rebaseline. * the input snippet might be optionally not wrapped in a top function, or not executed after compilation (--no-wrap and --no-execute). * the name of the wrapper can be configured using --wrapper-name=foo The same options can be configured via setters on the usual BytecodeExpectationsPrinter. The output file now includes all the relevant flags to reproduce it when running again through the tool (usually with --rebaseline). In particular, when running in --rebaseline mode, options from the file header will override options specified in the command line. A couple of other fixes and improvements: * description of the handlers is now emitted (closing the TODO). * the snippet is now correctly unquoted when double quotes are used. * special registers (closure, context etc.) are now emitted as such, instead of displaying their numeric value. * the tool can now process top level code as well. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1698403002 Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:36:26 +00:00
bool execute_;
bool wrap_;
bool top_level_;
std::string test_function_name_;
static const char* const kDefaultTopFunctionName;
[interpreter] Add checks for source position to test-bytecode-generator. Prints source position information alongside bytecode. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/1963663002 Cr-Commit-Position: refs/heads/master@{#36171}
2016-05-11 12:21:56 +00:00
static const char* const kIndent;
[Interpreter] Change the output format of generate-bytecode-expectations. Now the tool produces a far more readable output format, which bears a lot of resemblance to YAML. In fact, the output should be machine parseable as such, one document per testcase. However, the output format may be subject to changes in future, so don't rely on this property. In general, the output format has been optimized for producing a meaningful textual diff, while keeping a decent readability as well. Therefore, not everything is as compact as it could be, e.g. for an empty const pool we get: constant pool: [ ] instead of: constant pool: [] Also, trailing commas are always inserted in lists. Additionally, now the tool accepts its output format as input. When operating in this mode, all the snippets are extracted, processed and the output is then emitted as usual. If nothing has changed, the output should match the input. This is very useful for catching bugs in the bytecode generation by running a textual diff against a known-good file. The core (namely bytecode-expectations.cc) has been extracted from the original cc file, which provides the utility as usual. The definitions in the matching header of the library have been moved into the v8::internal::interpreter namespace. The library exposes a class ExpectationPrinter, with a method PrintExpectation, which takes a test snippet as input, and writes the formatted expectation to the supplied stream. One might then use a std::stringstream to retrieve the results as a string and run it through a diff utility. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1688383003 Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:19 +00:00
};
} // namespace interpreter
} // namespace internal
} // namespace v8
#endif // TEST_CCTEST_INTERPRETER_BYTECODE_EXPECTATIONS_PRINTER_H_
Reference in New Issue Copy Permalink