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. 20 Oct, 2017 2 commits
  5. 19 Oct, 2017 3 commits
  7. 18 Oct, 2017 2 commits
  9. 16 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [TurboFan] Model TypeOf as a simplified operator · 9b2a8c22
      Mike Stanton authored 
      Because the typeof operator may lower to a builtin call (which is
effectful in turbofan parlance after effect control linearization),
it really should be encoded as a simplified operator, which can
be optimized with respect for the effect chain in linearization.

No new functionality here, rather a furniture rearrangement in
the TurboFan node structure.

BUG=v8:6929

Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e
Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48613}
      9b2a8c22
  11. 29 Sep, 2017 1 commit
  13. 28 Sep, 2017 2 commits
    • Mostyn Bramley-Moore's avatar
      [jumbo] add unittests jumbo support · d6ead37d
      Mostyn Bramley-Moore authored 
      TBR=jkummerow@chromium.org

Bug: chromium:746958
Change-Id: I7500b6206c4ceb087672de5b61b7e7ad234bb425
Reviewed-on: https://chromium-review.googlesource.com/690397
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48213}
      d6ead37d
    • Enrico Bacis's avatar
      [wasm] Introduce the WasmContext · 6cd7a5a7
      Enrico Bacis authored 
      The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.

This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.

The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution.  The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.

This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).

R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org

Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
      6cd7a5a7
  15. 25 Sep, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored 
      When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.

The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from

  createEmptyArrayLiteral: 1846 ms.
  createShallowArrayLiteral: 1868 ms.
  createShallowObjectLiteral: 2246 ms.

to

  createEmptyArrayLiteral: 1175 ms.
  createShallowArrayLiteral: 1187 ms.
  createShallowObjectLiteral: 1195 ms.

with this CL, so up to 2x faster now.

Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.

Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
    • Clemens Hammacher's avatar
      [cleanup] [compiler] Fix (D)CHECK macros · 7ed27c47
      Clemens Hammacher authored 
      Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.

This will allow us to reenable the readability/check cpplint check.

R=jarin@chromium.org

Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
      7ed27c47
  17. 14 Sep, 2017 1 commit
  19. 13 Sep, 2017 1 commit
  21. 12 Sep, 2017 1 commit
  23. 07 Sep, 2017 1 commit
  25. 31 Aug, 2017 1 commit
  27. 30 Aug, 2017 1 commit
  29. 28 Aug, 2017 1 commit
  31. 17 Aug, 2017 1 commit
    • Leszek Swirski's avatar
      [turbofan] Never generate loop exit phis for the accumulator · 1a302730
      Leszek Swirski authored 
      The accumulator should never be alive when jumping back to a loop
header, or jumping out of a loop. This means that as far as far as
TurboFan is concerned, we never need to create Phis or LoopExitValues
for the accumulator, as its value should not escape the loop.

For safety, this also augments the IsLivenessValid DCHECK in the
liveness analysis to check that the accumulator is not live in these
cases, and amends the bytecode analysis tests to kill the accumulator
where necessary to ensure this.

As a drive-by, added some comments to the more complex bytecode analysis
tests, since figuring out what they were for and how to fix them took a
non-trivial amount of time.

Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
Reviewed-on: https://chromium-review.googlesource.com/615168
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47388}
      1a302730
  33. 11 Aug, 2017 1 commit
  35. 10 Aug, 2017 1 commit
  37. 08 Aug, 2017 1 commit
  39. 07 Aug, 2017 1 commit
  41. 03 Aug, 2017 3 commits
  43. 31 Jul, 2017 1 commit
  45. 28 Jul, 2017 4 commits
  47. 19 Jul, 2017 1 commit
  49. 14 Jul, 2017 2 commits
  51. 13 Jul, 2017 1 commit
  53. 12 Jul, 2017 1 commit
  55. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored 
      Each reducer now has a virtual reducer_name function, returning its name
(the name of the class containing this reducer). This gets displayed when
using the --trace_turbo_reduction flag. Also when using this flags more
messages are displayed.

Actually when a node is replaced in-place (which is called an update
of the node), other reducers can still update it right after the
in-place replacement. When a node is really replaced (not in-place),
then we stop trying to apply reducers to it before we propagate the
reduction through the relevant nodes.

Before a message got printed only for the last reduction it went
through. So in case a node was reduced in-place several times
in a row, only the last update was printed, or none at all if after
being reduced in-place it got reduced by being replaced by another
node: only the non-in-place replacement was showed. 

Now each time an in-place reduction is applied to a node, a message
gets printed.

Bug: 
Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Alexandre Talon <alexandret@google.com>
Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34