Skip to content

V
V8
Switch branch/tag
  1. 29 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add support for huge DataViews. · 15c31fe4
      Benedikt Meurer authored 
      This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.

The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.

The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.

This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from

  testDataViewGetUint8: 796 ms.
  testDataViewGetUint16: 997 ms.
  testDataViewGetInt32: 994 ms.
  testDataViewGetFloat64: 997 ms.

to

  testDataViewGetUint8: 895 ms.
  testDataViewGetUint16: 889 ms.
  testDataViewGetInt32: 888 ms.
  testDataViewGetFloat64: 890 ms.

meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.

Design-Document: http://bit.ly/turbofan-word64
Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
Reviewed-on: https://chromium-review.googlesource.com/c/1303732Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57095}
      15c31fe4
  3. 25 Oct, 2018 1 commit
  5. 10 Oct, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Use a tuple as the instance for JS imports · a2b34806
      Ben L. Titzer authored 
      This CL refactors the implementation of WASM->JS import wrappers in order
to make the wrapper code shareable. Instead of specializing to the import
index, we use a tuple as the object ref in the both the import and indirect
tables. The tuple allows the wrapper code to load both the calling
instance and the target callable, rather than relying on code specialization.

This requires some tricky codegen machinery, because WASM call descriptors
expect an instance argument in a given register, yet the wrappers receive
a tuple, the code generator must generate a prologue that loads the
instance (and the callable), since it is not possible to express this at
the graph level.

R=mstarzinger@chromium.org
CC=clemensh@chromium.org

Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
Reviewed-on: https://chromium-review.googlesource.com/c/1268237
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56520}
      a2b34806
  7. 20 Sep, 2018 1 commit
  9. 19 Sep, 2018 1 commit
  11. 17 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 0c296cb2
      Benedikt Meurer authored 
      This change introduces the necessary conversion operators to convert
from Word64 to other representations (Tagged, Word32, Float64, etc.),
and plugs in the Word64 representation for NumberAdd/NumberSubtract,
such that TurboFan will go to Int64Add/Sub on 64-bit architectures
when the inputs and the output of the operation is in safe integer
range. This includes the necessary changes to the Deoptimizer to be
able to rematerialize Int64 values as Smi/HeapNumber when going back
to Ignition later.

This change might affect performance, although measurements indicate
that there should be no noticable performance impact.

The goal is to have TurboFan support Word64 representation to a degree
that changing the TypedArray length to an uint64_t (for 64-bit archs)
becomes viable and doesn't have any negative performance implications.
Independent of that we might get performance improvements in other areas
such as for crypto code later.

Bug: v8:4153, v8:7881, v8:8171, v8:8178
Design-Document: bit.ly/turbofan-word64
Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1225709
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55937}
      0c296cb2
  13. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored 
      This adds support to TurboFan's representation selection for the Word64
representation, and makes use of that to handle indices for memory access
and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
etc.). These instructions had previously used Word32 as representation
for the indices / sizes, and then internally converted it to the correct
representation (aka Word64 on 64-bit architectures) later on, but that
was kind of brittle, and sometimes led to weird generated code.

The change thus only adds support to convert integer values in the safe
integer range from all kinds of representations to Word64 (on 64-bit
architectures). We don't yet handle the opposite direction and none of
the representation selection heuristics for the numeric operations were
changed so far. This will be done in follow-up CLs.

This CL itself is supposed to be neutral wrt. functionality, and only
serves as a starting point, and a cleanup for the (weird) implicit
Word64 index/size handling.

Bug: v8:7881, v8:8015, v8:8171
Design-Document: http://bit.ly/turbofan-word64
Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
Reviewed-on: https://chromium-review.googlesource.com/1224932
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  15. 23 Aug, 2018 1 commit
  17. 22 Aug, 2018 1 commit
  19. 14 Aug, 2018 3 commits
    • Georgia Kouveli's avatar
      [arm64] Clean up of move operations. · de3f3cf0
      Georgia Kouveli authored 
      * Perform the lookups into the builtins constant table and external reference
  table in the generic version of Mov that accepts an Operand source. This
  makes sure we do not miss looking up constants and external references when
  the generic Mov is called.
* Remove Mov(ExternalReference) as ExternalReference can be implicitly converted
  to an Operand.
* Remove two Move functions that are unused in architecture-independent code.
  Replace their uses in arm64-specific code with the generic Mov, which does all
  the necessary work now.

Change-Id: Ibbcee6ba22f661984cd830717e14c9b35a1fba0a
Reviewed-on: https://chromium-review.googlesource.com/1172351
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55121}
      de3f3cf0
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · 5fecd146
      Benedikt Meurer authored 
      This adds support for unaligned load/store access to the DataView
backing store and uses byteswap operations to fix up the endianess
when necessary. This changes the Word32ReverseBytes operator to be
a required operator and adds the missing support on the Intel and
ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
is also mandatory now).

This further improves the performance on the dataviewperf.js test
mentioned in the tracking bug by up to 40%, and at the same time
reduces the code complexity in the EffectControlLinearizer.

Bug: chromium:225811
Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55111}
      5fecd146
    • Leszek Swirski's avatar
      Revert "[turbofan] Further optimize DataView accesses." · 6a62d88e
      Leszek Swirski authored 
      This reverts commit c46915b9.

Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 

Original change's description:
> [turbofan] Further optimize DataView accesses.
> 
> This adds support for unaligned load/store access to the DataView
> backing store and uses byteswap operations to fix up the endianess
> when necessary. This changes the Word32ReverseBytes operator to be
> a required operator and adds the missing support on the Intel and
> ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
> is also mandatory now).
> 
> This further improves the performance on the dataviewperf.js test
> mentioned in the tracking bug by up to 40%, and at the same time
> reduces the code complexity in the EffectControlLinearizer.
> 
> Bug: chromium:225811
> Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
> Reviewed-on: https://chromium-review.googlesource.com/1172777
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55099}

TBR=sigurds@chromium.org,bmeurer@chromium.org

Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:225811
Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55107}
      6a62d88e
  21. 13 Aug, 2018 2 commits
  23. 27 Jul, 2018 1 commit
  25. 25 Jul, 2018 3 commits
  27. 13 Jul, 2018 1 commit
    • Bill Budge's avatar
      [wasm simd] Fuzz test the shuffle opcode · d950fc47
      Bill Budge authored 
      - Reorganizes shuffle tests into tabular form.
- Adds a test that composes random numbers of random shuffles to
  make new shuffles.
- Adds a test that generates functions to compute a complex expression
  consisting of shuffles, and compares interpreter results to compiled
  code results.
- Fixes a problem with temp register exhaustion on ARM 32-bit.
- Matches identity shuffles (returning first or second operand
  unchanged) and uses EmitIdentity() for these.

Bug: v8:6020
Change-Id: Ie41c14fee52a7406b1d32e731e050096400e12f5
Reviewed-on: https://chromium-review.googlesource.com/1119567
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54446}
      d950fc47
  29. 10 Jul, 2018 2 commits
  31. 05 Jul, 2018 1 commit
  33. 04 Jul, 2018 2 commits
  35. 03 Jul, 2018 1 commit
  37. 20 Jun, 2018 1 commit
  39. 19 Jun, 2018 1 commit
  41. 18 Jun, 2018 1 commit
  43. 15 Jun, 2018 1 commit
  45. 13 Jun, 2018 1 commit
  47. 12 Jun, 2018 1 commit
  49. 11 Jun, 2018 1 commit
  51. 07 Jun, 2018 1 commit
  53. 06 Jun, 2018 2 commits
  55. 05 Jun, 2018 1 commit
  57. 04 Jun, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Make stack check independent of the Isolate. · c96ac82c
      Michael Starzinger authored 
      This makes stack checks in WasmCode independent of the underlying
Isolate by loading the limit address from the WasmInstanceObject instead
of embedding it into the instruction stream. It hence removes the last
use of the Isolate field from WasmGraphBuilder.

Additionally this introduces the notion of a "runtime stub" which
represents stub code global to the NativeModule that can be directly
called from each WasmCode in the same module. These stubs can act as
trampolines via which Isolate-independent WasmCode can enter other V8
builtins or runtime functions that remain Isolate-dependent. They will
eventually replace the current "trampoline" in a NativeModule.

R=titzer@chromium.org
BUG=v8:7424

Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74
Reviewed-on: https://chromium-review.googlesource.com/1078732
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53487}
      c96ac82c
  59. 25 May, 2018 1 commit
    • jgruber's avatar
      [builtins,x64] pc-relative builtin-to-builtin calls · e5630ea9
      jgruber authored 
      This addresses one of the major remaining slowdowns with embedded
builtins on x64.

When generating code for a call to a builtin callee from a builtin
caller, we'd look up the Code target object from the builtins constant
list, calculate the location of the first instruction, and jump to it.
Note that for embedded builtin callees, the Code object is itself only
a trampoline to the off-heap code and thus an additional indirection.
An example of the call sequence in pseudo-asm:

// Load from the constants list.
mov reg, [kRootPointer, kBuiltinsConstantListOffset]
mov reg, [reg, offset_of_the_code_constant]
// Calculate first instruction and call it.
add reg, Code::kHeaderOffset
call reg
// The trampoline forwards to the off-heap area.
mov kOffHeapTrampolineRegister, <off-heap instruction_start>
jmp kOffHeapTrampolineRegister

This CL changes calls to embedded builtin targets to use pc-relative
addressing. This reduces the above instruction sequence to:

call <pc-relative offset to target instruction_start>

Embedded-to-embedded calls jump directly to the embedded instruction
stream, bypassing the trampoline. Heap-to-embedded calls (and all
calls to heap-builtins) use pc-relative addressing targeting the
on-heap Code object.

Other relevant platforms (arm,arm64,mips,mips64) do not use pc-relative
calls. For these, we'll need a different solution, e.g. a table of
embedded builtin addresses reachable from the root pointer, similar to
the external reference table.

Bug: v8:6666
Change-Id: Ic0317d454e2da37d74eaecebcdfcbc0d5f5041ad
Reviewed-on: https://chromium-review.googlesource.com/1068732
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53349}
      e5630ea9
  61. 09 May, 2018 1 commit
  63. 02 May, 2018 1 commit