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}
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}
Apparently, this BytecodeArrayIterator method was missed during the
previous refactor. No other (collateral) change was done.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1691433002
Cr-Commit-Position: refs/heads/master@{#33909}
This is a follow-up to https://crrev.com/1671863002, adding the
capability to print the contents of the constant pool. The expected
type of the pool is taken from command line, and it's either:
* string/int/double: assume all constants have the specified type.
This way, we can emit a meaningful representation, e.g. a quoted
string for type string and so on. All the constants in the pool must
have the same type, otherwise one or more CHECK() will fail and the
program will eventually crash.
* mixed: print the InstanceType tag instead of the actual value.
This is the choice for those tests where the type of the constants in
the pool is not uniform, however only a type tag is printed, not the
actual value of the entries. SMIs are an exception, since they do not
have an InstanceType tag, so kInstanceTypeDontCare is printed instead.
In addition to that, functions Print{ExpectedSnippet,BytecodeSequence}
have been extracted with no functional change. It's just for improving
readability, since the code is becoming quite long.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1686963002
Cr-Commit-Position: refs/heads/master@{#33888}
The previous implementation used GetRawOperand(), which allows a nicely
unified handling of all scalar types, but returns an unsigned type.
Because of this, generate-bytecode-expectations couldn't properly handle
negative numbers.
This commit differentiate between different types of scalar operands and
uses the appropriate getter from i::interpreter::BytecodeArrayIterator,
thus correctly handling signed types where needed.
Two new helpers have been added to i::interpreter::Bytecodes:
* IsImmediateOperandType()
* IsIndexOperandType()
with the intuitive semantic.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1684113002
Cr-Commit-Position: refs/heads/master@{#33874}
generate-bytecode-expectations is a tool intended to work together
with test/cctest/test-bytecode-generator.cc in order to produce a
meaningful diff between testcases and the actual bytecode being emitted.
It does so by parsing and compiling Javascript to bytecode,
constructing the same data structure in the testcase and then running a
textual diff between the expected (i.e. the one encoded in the unit test)
and actual (i.e. the one built from the compiler output) representation.
This commit is a first step in this direction, achieving just the first
half of what we desire. At the moment, bytecodechecker can:
* take a code snippet from the command line and emit the expected structure.
* adhere to the same formatting rules of the test cases
(this one is important for text diff and for copy and pasting too)
Still to do:
* parse unit tests:
+ extract code snippets
+ indent the code to match the input test case
+ allow flexibility in the input format
+ try to recognize and work around some macro magic (i.e. REPEAT_127)
* emit the representation of the constant pool and handlers vector
* run a textual diff
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1671863002
Cr-Commit-Position: refs/heads/master@{#33863}
