1. 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
  2. 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
  3. 10 Feb, 2020 1 commit
  4. 23 Aug, 2017 1 commit
    • Adam Klein's avatar
      [ignition] Fix return value of delete on global lexical variables · ac0a2df3
      Adam Klein authored
      BytecodeGenerator previously assumed that any UNALLOCATED variable
      must be a global object property, but that's incorrect for global
      lexical variables declared in a different script.
      
      This patch fixes the behavior by always falling back to the runtime
      to deal with deleting UNALLOCATED variables. This is sub-optimal,
      but should be correct, and it's unclear if speed is important for
      this case.
      
      Bug: v8:6733
      Change-Id: I83c2a0b6e30e5e5f4c79bfe14ebf196529816c71
      Reviewed-on: https://chromium-review.googlesource.com/627636Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47554}
      ac0a2df3
  5. 27 Jul, 2017 1 commit
  6. 25 Jul, 2017 1 commit
  7. 17 Jul, 2017 1 commit
    • Leszek Swirski's avatar
      Revert "[runtime] Move profiler ticks from SFI to feedback vector" · 14c5c4fd
      Leszek Swirski authored
      This reverts commit a2fcdc7c.
      
      Reason for revert: Large regressions in RCS (https://chromeperf.appspot.com/group_report?bug_id=740126)
      
      Original change's description:
      > [runtime] Move profiler ticks from SFI to feedback vector
      > 
      > Instead of counting profiler ticks on the shared function info (which is
      > shared between native contexts), count them on the feedback vector
      > (which is not). This allows us to continue pushing optimization
      > decisions off the SFI, onto the feedback vector.
      > 
      > Note that a side-effect of this is that ICs don't have to walk the stack
      > to reset profiler ticks, as they can access the feedback vector directly
      > from their feedback nexus.
      > 
      > Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
      > Reviewed-on: https://chromium-review.googlesource.com/544888
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46411}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,ishell@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: Id587e4172e300c420f93c49744a2a0e66696edf8
      Reviewed-on: https://chromium-review.googlesource.com/574227
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46702}
      14c5c4fd
  8. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  9. 05 Jul, 2017 1 commit
  10. 10 May, 2017 1 commit
  11. 08 May, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "Reland: [TypeFeedbackVector] Store optimized code in the vector" · fd749344
      Ross McIlroy authored
      This reverts commit 662aa425.
      
      Reason for revert: Crashing on Canary
      BUG=chromium:718891
      
      Original change's description:
      > Reland: [TypeFeedbackVector] Store optimized code in the vector
      > 
      > Since the feedback vector is itself a native context structure, why
      > not store optimized code for a function in there rather than in
      > a map from native context to code? This allows us to get rid of
      > the optimized code map in the SharedFunctionInfo, saving a pointer,
      > and making lookup of any optimized code quicker.
      > 
      > Original patch by Michael Stanton <mvstanton@chromium.org>
      > 
      > BUG=v8:6246
      > TBR=yangguo@chromium.org,ulan@chromium.org
      > 
      > Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      > Reviewed-on: https://chromium-review.googlesource.com/494487
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#45084}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
      # Not skipping CQ checks because original CL landed > 1 day ago.
      BUG=v8:6246
      
      Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
      Reviewed-on: https://chromium-review.googlesource.com/498633Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45174}
      fd749344
  12. 04 May, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [TypeFeedbackVector] Store optimized code in the vector · 662aa425
      Ross McIlroy authored
      Since the feedback vector is itself a native context structure, why
      not store optimized code for a function in there rather than in
      a map from native context to code? This allows us to get rid of
      the optimized code map in the SharedFunctionInfo, saving a pointer,
      and making lookup of any optimized code quicker.
      
      Original patch by Michael Stanton <mvstanton@chromium.org>
      
      BUG=v8:6246
      TBR=yangguo@chromium.org,ulan@chromium.org
      
      Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
      Reviewed-on: https://chromium-review.googlesource.com/494487Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45084}
      662aa425
  13. 02 May, 2017 2 commits
  14. 07 Mar, 2017 1 commit
  15. 25 Jan, 2017 1 commit
  16. 16 Nov, 2016 1 commit
  17. 10 Nov, 2016 1 commit
  18. 28 Oct, 2016 1 commit
  19. 04 Oct, 2016 1 commit
  20. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored
      Add a notion of "invocation count" to the baseline compilers, which
      increment a special slot in the TypeFeedbackVector for each invocation
      of a given function (the optimized code doesn't currently collect this
      information).
      
      Use this invocation count to relativize the call counts on the call
      sites within the function, so that the inlining heuristic has a view
      of relative importance of a call site rather than some absolute numbers
      with unclear meaning for the current function. Also apply the call site
      frequency as a factor to all frequencies in the inlinee by passing this
      to the graph builders so that the importance of a call site in an
      inlinee is relative to the topmost optimized function.
      
      Note that all functions that neither have literals nor need type
      feedback slots will share a single invocation count cell in the
      canonical empty type feedback vector, so their invocation count is
      meaningless, but that doesn't matter since we only use the invocation
      count to relativize call counts within the function, which we only have
      if we have at least one type feedback vector (the CallIC slot).
      
      See the design document for additional details on this change:
      https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
      
      BUG=v8:5267,v8:5372
      R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
      
      Review-Url: https://codereview.chromium.org/2337123003
      Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36
  21. 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
  22. 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
  23. 27 Jun, 2016 1 commit
  24. 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
  25. 11 May, 2016 1 commit
  26. 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
  27. 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