1. 10 Jun, 2022 1 commit
  2. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  3. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  4. 10 Feb, 2020 1 commit
  5. 25 Jan, 2017 1 commit
  6. 04 Oct, 2016 1 commit
  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. 21 Jun, 2016 1 commit
  9. 01 Jun, 2016 1 commit
  10. 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
  11. 11 May, 2016 1 commit
  12. 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
  13. 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