1. 27 Nov, 2018 1 commit
  2. 25 Nov, 2018 1 commit
  3. 10 Aug, 2018 1 commit
  4. 09 Aug, 2018 1 commit
  5. 08 Aug, 2018 1 commit
  6. 07 Aug, 2018 1 commit
  7. 13 Oct, 2017 1 commit
  8. 04 Oct, 2016 2 commits
  9. 06 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Remove constant pool type in tests · b28b7e13
      leszeks authored
      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}
      b28b7e13
  10. 28 Jun, 2016 1 commit
  11. 11 May, 2016 1 commit
  12. 25 Feb, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] Refactor bytecode generator test suite. · 6ae03059
      ssanfilippo authored
      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}
      6ae03059
  13. 19 Feb, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] generate-bytecode-expectations improvements. · d2187182
      ssanfilippo authored
      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}
      d2187182
  14. 15 Feb, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] Change the output format of generate-bytecode-expectations. · e082ebdb
      ssanfilippo authored
      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}
      e082ebdb