1. 04 Oct, 2016 1 commit
  2. 09 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Fix destroyed new.target register use. · 0681deb9
      mstarzinger authored
      This fixes a corner-case where the bytecode was using the <new.target>
      register directly without going through the local variable. The value
      might be clobbered because the deoptimizer doesn't properly restore the
      value. The label will causes bytecode pipeline to be flushed and hence
      ensure {BytecodeRegisterOptimizer} doesn't reuse <new.target> anymore.
      
      R=rmcilroy@chromium.org
      TEST=mjsunit/regress/regress-crbug-645103
      BUG=chromium:645103
      
      Review-Url: https://codereview.chromium.org/2325133002
      Cr-Commit-Position: refs/heads/master@{#39306}
      0681deb9
  3. 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
  4. 05 Aug, 2016 1 commit
    • adamk's avatar
      Use Variable::binding_needs_init() to determine hole initialization · 6768456d
      adamk authored
      The old code was using VariableMode, but that signal is both
      over-pessimistic (some CONST and LET variables need no hole-initialization)
      and inconsistent with other uses of the InitializationFlag enum (such
      as %LoadLookupSlot).
      
      This changes no observable behavior, but removes unnecessary hole
      initialization and hole checks in a few places, including
      block-scoped function declarations, super property lookups,
      and new.target.
      
      R=bmeurer@chromium.org, neis@chromium.org
      
      Review-Url: https://codereview.chromium.org/2201193004
      Cr-Commit-Position: refs/heads/master@{#38395}
      6768456d
  5. 04 Jun, 2016 1 commit
  6. 27 May, 2016 1 commit
  7. 11 May, 2016 1 commit
  8. 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