1. 22 Dec, 2016 1 commit
  2. 21 Dec, 2016 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Root literal arrays in function literals slots · 93df0940
      mvstanton authored
      Literal arrays and feedback vectors for a function can be garbage
      collected if we don't have a rooted closure for the function, which
      happens often. It's expensive to come back from this (recreating
      boilerplates and gathering feedback again), and the cost is
      disproportionate if the function was inlined into optimized code.
      
      To guard against losing these arrays when we need them, we'll now
      create literal arrays when creating the feedback vector for the outer
      closure, and root them strongly in that vector.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2504153002
      Cr-Commit-Position: refs/heads/master@{#41893}
      93df0940
  3. 10 Nov, 2016 1 commit
  4. 28 Oct, 2016 1 commit
  5. 04 Oct, 2016 1 commit
  6. 13 Sep, 2016 1 commit
    • leszeks's avatar
      [Interpreter] Move context chain search loop to handler · 1c0c5fda
      leszeks authored
      Moves the context chain search loop out of generated bytecode, and into
      the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
      an additional operand. This should decrease the bytecode size and
      increase performance for deep context chain searches, at the cost of
      slightly increasing bytecode size for shallow context access.
      
      Review-Url: https://codereview.chromium.org/2336643002
      Cr-Commit-Position: refs/heads/master@{#39378}
      1c0c5fda
  7. 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
  8. 09 Aug, 2016 1 commit
  9. 03 Aug, 2016 1 commit
  10. 30 Jun, 2016 1 commit
  11. 27 May, 2016 1 commit
  12. 25 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce fused bytecodes for common sequences. · 25b3fe79
      oth authored
      This change introduces five fused bytecodes for common bytecode
      sequences on popular websites. These are LdrNamedProperty,
      LdrKeyedProperty, LdrGlobal, LdrContextSlot, and LdrUndefined. These
      load values into a destination register operand instead of the
      accumulator. They are emitted by the peephole optimizer.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1985753002
      Cr-Commit-Position: refs/heads/master@{#36507}
      25b3fe79
  13. 23 May, 2016 1 commit
    • oth's avatar
      [Interpreter] Preserve source positions in peephole optimizer. · e43fbde7
      oth authored
      The original peephole optimizer logic in the BytecodeArrayBuilder did
      not respect source positions as it was written before there were
      bytecode source positions. This led to some minor differences to
      FCG and was problematic when combined with pending bytecode
      optimizations. This change makes the new peephole optimizer fully
      respect source positions.
      
      BUG=v8:4280
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1998203002
      Cr-Commit-Position: refs/heads/master@{#36439}
      e43fbde7
  14. 11 May, 2016 1 commit
  15. 29 Apr, 2016 1 commit
  16. 21 Mar, 2016 1 commit
    • oth's avatar
      [interpreter] Add support for scalable operands. · 48d082af
      oth authored
      This change introduces wide prefix bytecodes to support wide (16-bit)
      and extra-wide (32-bit) operands. It retires the previous
      wide-bytecodes and reduces the number of operand types.
      
      Operands are now either scalable or fixed size. Scalable operands
      increase in width when a bytecode is prefixed with wide or extra-wide.
      
      The bytecode handler table is extended to 256*3 entries. The
      first 256 entries are used for bytecodes with 8-bit operands,
      the second 256 entries are used for bytecodes with operands that
      scale to 16-bits, and the third group of 256 entries are used for
      bytecodes with operands that scale to 32-bits.
      
      LOG=N
      BUG=v8:4747,v8:4280
      
      Review URL: https://codereview.chromium.org/1783483002
      
      Cr-Commit-Position: refs/heads/master@{#34955}
      48d082af
  17. 08 Mar, 2016 1 commit
    • verwaest's avatar
      Don't do any special normalization if a boilerplate contains function literals. · fd405704
      verwaest authored
      This mechanism was used to ensure that functions ended up as constants on the map of prototypes defined using object literals, e.g.,:
      
      function.prototype = {
        method: function() { ... }
      }
      
      Nowadays we treat prototypes specially, and make all their functions constants when an object turns prototype. Hence this special custom code isn't necessary anymore.
      
      This also affects boilerplates that do not become prototypes. Their functions will not be constants but fields instead. Calling their methods will slow down. However, multiple instances of the same boilerplate will stay monomorphic. We'll have to see what the impact is for such objects, but preliminary benchmarks do not show this as an important regression.
      
      BUG=chromium:593008
      LOG=n
      
      Review URL: https://codereview.chromium.org/1772423002
      
      Cr-Commit-Position: refs/heads/master@{#34602}
      fd405704
  18. 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