Skip to content

V
V8
Switch branch/tag
  1. 23 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce InstanceOfIC to collect rhs feedback. · bcee1406
      Benedikt Meurer authored 
      This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
constant feedback about the right-hand side of instanceof operators,
including both JSFunction and JSBoundFunction instances. TurboFan then
uses the feedback to optimize instanceof in places where the right-hand
side is not a known constant (known to TurboFan).

This addresses the odd performance cliff that we see with instanceof in
functions with multiple closures. It was discovered as one of the main
bottlenecks on the uglify-es test in the web-tooling-benchmark. The
uglify-es test (run in separation) is ~18% faster with this change.

On the micro-benchmark in the tracking bug we go from

  instanceofSingleClosure_Const: 69 ms.
  instanceofSingleClosure_Class: 246 ms.
  instanceofMultiClosure: 246 ms.
  instanceofParameter: 246 ms.

to

  instanceofSingleClosure_Const: 70 ms.
  instanceofSingleClosure_Class: 75 ms.
  instanceofMultiClosure: 76 ms.
  instanceofParameter: 73 ms.

boosting performance by roughly 3.6x and thus effectively removing the
performance cliff around instanceof.

Bug: v8:6936, v8:6971
Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
Reviewed-on: https://chromium-review.googlesource.com/730686
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48820}
      bcee1406
  3. 27 Jul, 2017 1 commit
  5. 25 Jul, 2017 1 commit
  7. 18 Jul, 2017 1 commit
  9. 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
  11. 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
  13. 05 Jul, 2017 1 commit
  15. 10 May, 2017 1 commit
  17. 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
  19. 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
  21. 03 May, 2017 1 commit
  23. 02 May, 2017 2 commits
  25. 10 Apr, 2017 1 commit
    • Ross McIlroy's avatar
      Reland: [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator."" · 496864f8
      Ross McIlroy authored 
      This relands commit d3e9aade. The original CL was reverted speculatively but didn't cause the buildbot failure.

Original change's description:
> [Interpreter] Move BinaryOp Smi transformation into BytecodeGenerator.
> 
> Perform the transformation to <BinaryOp>Smi for Binary ops which take Smi
> literals in the BytecodeGenerator. This enables us to perform the
> transformation for literals on either side for commutative operations, and
> Avoids having to do the check on every bytecode in the peephole optimizer.
> 
> In the process, adds Smi bytecode variants for all binary operations, adding
>  - MulSmi
>  - DivSmi
>  - ModSmi
>  - BitwiseXorSmi
>  - ShiftRightLogical
> 
> BUG=v8:6194
> 
> Change-Id: If1484252f5385c16957004b9cac8bfbb1f209219
> Reviewed-on: https://chromium-review.googlesource.com/466246
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44477}

TBR=rmcilroy@chromium.org,machenbach@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,mythria@chromium.org,v8-reviews@googlegroups.com,ishell@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6194

Change-Id: I2ccaefa1ce58d3885f5c2648755985c06f25c1d8
Reviewed-on: https://chromium-review.googlesource.com/472746Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44511}
      496864f8
  27. 07 Apr, 2017 2 commits
  29. 25 Jan, 2017 1 commit
  31. 04 Oct, 2016 1 commit
  33. 26 Sep, 2016 2 commits
    • bmeurer's avatar
      Revert of [compiler] Properly guard the speculative optimizations for... · b9cdb630
      bmeurer authored 
      Revert of [compiler] Properly guard the speculative optimizations for instanceof. (patchset #3 id:40001 of https://codereview.chromium.org/2370693002/ )

Reason for revert:
Tanks EarleyBoyer.

Original issue's description:
> [compiler] Properly guard the speculative optimizations for instanceof.
>
> Add a general feedback slot for instanceof similar to what we already have
> for for-in, which basically has a fast (indicated by the uninitialized
> sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
> we can only take the fast path when the feedback slot says it hasn't
> seen any funky inputs and nothing funky appeared in the prototype chain.
> In the TurboFan code we also deoptimize whenever we see a funky object
> (i.e. a proxy or an object that requires access checks) in the prototype
> chain (similar to what Crankshaft already did).
>
> Drive-by-fix: Also make Crankshaft respect the mode and therefore
> address the deopt loop in Crankshaft around instanceof.
>
> We might want to introduce an InstanceOfIC mechanism at some point and
> track the map of the right-hand side.
>
> BUG=v8:5267
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/a0484bc6116ebc2b855de87d862945e2ae07169b
> Cr-Commit-Position: refs/heads/master@{#39718}

TBR=mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5267

Review-Url: https://codereview.chromium.org/2365223003
Cr-Commit-Position: refs/heads/master@{#39736}
      b9cdb630
    • bmeurer's avatar
      [compiler] Properly guard the speculative optimizations for instanceof. · a0484bc6
      bmeurer authored 
      Add a general feedback slot for instanceof similar to what we already have
for for-in, which basically has a fast (indicated by the uninitialized
sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
we can only take the fast path when the feedback slot says it hasn't
seen any funky inputs and nothing funky appeared in the prototype chain.
In the TurboFan code we also deoptimize whenever we see a funky object
(i.e. a proxy or an object that requires access checks) in the prototype
chain (similar to what Crankshaft already did).

Drive-by-fix: Also make Crankshaft respect the mode and therefore
address the deopt loop in Crankshaft around instanceof.

We might want to introduce an InstanceOfIC mechanism at some point and
track the map of the right-hand side.

BUG=v8:5267
R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2370693002
Cr-Commit-Position: refs/heads/master@{#39718}
      a0484bc6
  35. 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
  37. 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
  39. 30 Aug, 2016 1 commit
  41. 23 Aug, 2016 1 commit
  43. 15 Aug, 2016 1 commit
  45. 05 Jul, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce binary op bytecodes for Smi operand. · 40511877
      oth authored 
      Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode.
The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi,
BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi.

There are additional code stubs for these operations that are biased towards
both the left hand and right hand operands being Smis.

BUG=v8:4280
LOG=N

Review-Url: https://codereview.chromium.org/2111923002
Cr-Commit-Position: refs/heads/master@{#37531}
      40511877
  47. 21 Jun, 2016 1 commit
  49. 09 Jun, 2016 1 commit
  51. 01 Jun, 2016 1 commit
  53. 27 May, 2016 1 commit
  55. 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
  57. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored 
      This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.

R=ishell@chromium.org
TBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n

Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  59. 11 May, 2016 1 commit
  61. 28 Apr, 2016 1 commit
  63. 12 Apr, 2016 1 commit
  65. 05 Apr, 2016 2 commits
  67. 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
  69. 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