1. 22 Feb, 2018 1 commit
  2. 12 Jan, 2018 1 commit
  3. 22 Dec, 2017 1 commit
  4. 28 Nov, 2017 2 commits
  5. 27 Nov, 2017 1 commit
    • Sathya Gunasekaran's avatar
      [class] Store class fields initializer on the constructor · 4ca9d843
      Sathya Gunasekaran authored
      Previously, the class fields initializer function was stored on a
      synthetic context allocated variable. This approach had sevaral
      problems:
      
      - We didn't know that class literal had fields until after we had
      completely parsed the class literal. This meant that we had to go back
      and fix up the scope of the constructor to have this synthetic
      variable. This resulted in mismatch between parser and preparsed scope
      data.
      
      - This synthetic variable could potentially resolve to an initializer
      of an outer class.
      
      For ex:
      class X extends Object {
        c = 1;
        constructor() {
          var t = () => {
            class P extends Object {
              constructor() {
                var t = () => { super(); };
                t();
              }
            }
            super();
          }
          t();
        }
      }
      
      In this the inner class P could access the outer class X's initiliazer
      function. We would have to maintain extra metadata to make sure this
      doesn't happen.
      
      Instead this new approach uses a private symbol to store the
      initializer function on the class constructor itself.
      
      For the base constructor case, we can simply check for a bit on the
      constructor function literal to see if we need to emit code that loads
      and calls this initializer function. Therefore, we don't pay the cost
      of loading this function in case there are no class fields.
      
      For the derived constructor case, there are two possiblities:
      (a) We are in a super() call directly in the derived constructor:
      
      In this case we can do a check similar to the base constructor check,
      we can check for a bit on the derived constructor and emit code for
      loading and calling the initializer function.
      
      This is usually the common case and we don't pay any cost for not using
      class fields.
      
      (b) We are in a super() call inside an arrow function in the derived
      constructor:
      
      In this case, we /always/ emit code to load and call the initializer
      function. If the function doesn't exist then we have undefined and we
      don't call anything. Otherwise we call the function.
      
      super() can't be called twice so even if we emit code to load and call
      the initializer function multiple times, it doesn't matter because it
      would have already been an error.
      
      Bug: v8:5367
      Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
      Reviewed-on: https://chromium-review.googlesource.com/781660
      Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49628}
      4ca9d843
  6. 14 Nov, 2017 1 commit
  7. 29 Aug, 2017 1 commit
  8. 10 Aug, 2017 1 commit
  9. 13 Jul, 2017 1 commit
  10. 22 May, 2017 1 commit
  11. 24 Feb, 2017 1 commit
  12. 04 Oct, 2016 2 commits
  13. 30 Sep, 2016 1 commit
  14. 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
  15. 31 Aug, 2016 1 commit
  16. 25 Jul, 2016 2 commits
  17. 29 Jun, 2016 1 commit
  18. 08 Jun, 2016 1 commit
  19. 20 Apr, 2016 1 commit
  20. 18 Apr, 2016 1 commit
  21. 22 Mar, 2016 1 commit
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
      are no more. This lets us remove a bunch of code from many parts of the
      codebase.
      
      In this patch, I remove parser support for generating legacy const variables
      from const declarations. This also removes the special "illegal declaration"
      bit from Scope, which has ripples into all compiler backends.
      
      Also gone are any tests which relied on legacy const declarations.
      
      Note that we do still generate a Variable in mode CONST_LEGACY in one case:
      function name bindings in sloppy mode. The likely fix there is to add a new
      Variable::Kind for this case and handle it appropriately for stores in each
      backend, but I leave that for a later patch to make this one completely
      subtractive.
      
      Review URL: https://codereview.chromium.org/1819123002
      
      Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
  22. 16 Mar, 2016 1 commit
  23. 01 Mar, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] Silence runtime errors in generate-bytecode-expectations. · dc71deb0
      ssanfilippo authored
      Runtime errors will be suppressed in --rebaseline mode, unless the
      --verbose flag is passed.
      
      The reasoning behind (rebaseline && !verbose) and not just (verbose)
      is to suppress harmless noise while updating the expectation for
      existing, known good snippets, without hiding actually relevant
      errors when the tool is used to write new expectation files.
      
      In fact, some tests are supposed to produce a runtime error, which
      might nevertheless alarm a developer who is just --rebaseline'ing.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1742723003
      
      Cr-Commit-Position: refs/heads/master@{#34385}
      dc71deb0
  24. 26 Feb, 2016 1 commit
  25. 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
  26. 19 Feb, 2016 3 commits
    • ssanfilippo's avatar
      [Interpreter] Fix generate-bytecode-expectations help message. · 67f75e30
      ssanfilippo authored
      --pool-type=int and double have now been merged into number.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1717633002
      
      Cr-Commit-Position: refs/heads/master@{#34164}
      67f75e30
    • ssanfilippo's avatar
      [Interpreter] Support relevant FLAG_s in generate-bytecode-expectations. · 4f0be519
      ssanfilippo authored
      FLAG_legacy_const and FLAG_harmony_do_expressions can now be toggled
      both through the command line and through the option header.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1716793002
      
      Cr-Commit-Position: refs/heads/master@{#34160}
      4f0be519
    • 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
  27. 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
  28. 11 Feb, 2016 2 commits
    • ssanfilippo's avatar
      Reland of [Interpreter] Rename GetCountOperand to GetRegisterCountOperand. · 2f0ac9a2
      ssanfilippo authored
      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}
      2f0ac9a2
    • ssanfilippo's avatar
      [Interpreter] Print constant pool in generate-bytecode-expectations · db52dbbb
      ssanfilippo authored
      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}
      db52dbbb
  29. 10 Feb, 2016 2 commits
    • ssanfilippo's avatar
      [Interpreter] Handle negative ints in generate-bytecode-expectations. · 8bfd4a5a
      ssanfilippo authored
      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}
      8bfd4a5a
    • ssanfilippo's avatar
      [Interpreter] Initial generate-bytecode-expectations implementation. · d3604cdb
      ssanfilippo authored
      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}
      d3604cdb