Skip to content

V
V8
Switch branch/tag
  1. 11 Apr, 2017 2 commits
  3. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored 
      Adds a collection of call bytecodes which have an implicit undefined
receiver argument, for cases such as global calls where we know that the
receiver has to be undefined. This way we can skip an LdaUndefined,
decrease bytecode register pressure, and set a more accurate
ConvertReceiverMode on the interpreter and TurboFan call.

As a side effect, the "normal" Call bytecode now becomes a rare case
(only with calls and super property calls), so we get rid of its 0-2
argument special cases and modify CallProperty[N] to use the
NotNullOrUndefined ConvertReceiverMode.

Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
Reviewed-on: https://chromium-review.googlesource.com/463287
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  5. 05 Apr, 2017 1 commit
  7. 30 Mar, 2017 1 commit
  9. 29 Mar, 2017 1 commit
  11. 22 Mar, 2017 1 commit
  13. 17 Mar, 2017 1 commit
  15. 15 Mar, 2017 1 commit
  17. 07 Mar, 2017 1 commit
  19. 10 Feb, 2017 1 commit
  21. 07 Feb, 2017 2 commits
  23. 06 Feb, 2017 1 commit
  25. 26 Jan, 2017 1 commit
    • mvstanton's avatar
      Interpreter tester should accept metadata instead of a vector · d24ce605
      mvstanton authored 
      The InterpreterTester class cobbles together a JSFunction from
a manually created bytecode and feedback vector. However it's
fragile against design changes in the way literal arrays and
feedback vectors are handled. It's better to let it hand in
a feedback vector metadata object, and allow the system to
create the vector from that.

BUG=v8:5456

Review-Url: https://codereview.chromium.org/2652893010
Cr-Commit-Position: refs/heads/master@{#42684}
      d24ce605
  27. 09 Jan, 2017 1 commit
  29. 03 Jan, 2017 1 commit
  31. 02 Jan, 2017 1 commit
  33. 17 Nov, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Collect String feedback on CompareOps. · 53698740
      rmcilroy authored 
      Collect string feedback for compare operations. Without this,
functions which have a lot of string compare operations end up with
a high generic type percentage, and don't get optimized until very
late.

Currently TurboFan doesn't use this String feedback for compare
operations, but this could be done in future work if it is useful.

BUG=chromium:660947

Review-Url: https://codereview.chromium.org/2506013005
Cr-Commit-Position: refs/heads/master@{#41078}
      53698740
  35. 27 Oct, 2016 1 commit
    • leszeks's avatar
      [ignition] Add a property call bytecode · c4d770b1
      leszeks authored 
      This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.

I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.

Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
      c4d770b1
  37. 17 Oct, 2016 1 commit
  39. 07 Oct, 2016 3 commits
  41. 05 Oct, 2016 5 commits
  43. 30 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Replace BytecodeRegisterAllocator with a simple bump pointer. · 27fe988b
      rmcilroy authored 
      There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.

The following changes are also made:
 - Make BytecodeRegisterOptimizer able to use registers which have been
   unallocated, but not yet reused
 - Remove RegisterExpressionResultScope and rename
   AccumulatorExpressionResultScope to ValueExpressionResultScope
 - Introduce RegisterList to represent consecutive register
   allocations, and use this for operands to call bytecodes.

By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.

BUG=v8:4280

Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
      27fe988b
  45. 23 Sep, 2016 1 commit
  47. 20 Sep, 2016 2 commits
    • mvstanton's avatar
      [TypeFeedbackVector] special ic slots for interpreter compare/binary ops. · b88d132f
      mvstanton authored 
      Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.

As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.

This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.

BUG=

Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
      b88d132f
    • leszeks's avatar
      [interpreter] Add fast path for dynamic global lookups · 044a62be
      leszeks authored 
      Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.

BUG=v8:5263

Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}
      044a62be
  49. 16 Sep, 2016 1 commit
  51. 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
  53. 13 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Merge {OsrPoll} with {Jump} bytecode. · c9864173
      mstarzinger authored 
      This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.

R=rmcilroy@chromium.org
BUG=v8:4764

Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
      c9864173
  55. 30 Aug, 2016 1 commit
  57. 23 Aug, 2016 1 commit
  59. 19 Aug, 2016 1 commit
  61. 18 Aug, 2016 1 commit