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. 01 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Unify handling of zeros. · 8ead5698
      Benedikt Meurer authored 
      Following up on the earlier work regarding redundant Smi checks in
https://chromium-review.googlesource.com/c/v8/v8/+/1246181, it was
noticed that the handling of the 0 and -0 and how some operations
identify these is not really consistent, but was still rather ad-hoc.
This change tries to unify the handling a bit by making sure that all
number comparisons generally pass truncations that identify zeros, since
for the number comparisons in JavaScript there's no difference between
0 and -0. In the same spirit NumberAbs and NumberToBoolean should also
pass these truncations, since they also don't care about the differences
between 0 and -0.

Adjust NumberCeil, NumberFloor, NumberTrunc, NumberMin and NumberMax
to pass along any incoming kIdentifiesZeros truncation, since these
operations also don't really care whether the inputs can be -0 if the
use nodes don't care.

Also utilize the kIdentifiesZeros truncation for NumberModulus with
Signed32 inputs, because it's kind of common to do something like
`x % 2 === 0`, where it doesn't really matter whether `x % 2` would
eventually produce a negative zero (since that would still be considered
true for the sake of the comparison).

This also adds a whole lot of tests to ensure that not only are these
optimizations correct, but also that we do indeed perform them.

Drive-by-fix: The `NumberAbs(x)` would incorrectly lower to just `x` for
PositiveIntegerOrMinusZeroOrNaN inputs, which was obviously wrong in
case of -0. This was fixed as well, and an appropriate test was added.

The reason for the unification is that with the introduction of Word64
for CheckBounds (which is necessary to support large TypedArrays and
DataViews) we can no longer safely pass Word32 truncations for the
interesting cases, since the index might be outside the Signed32 or
Unsigned32 ranges, but we still identify 0 and -0 for the sake of the
bounds check, and so it's important that this is handled consistently
to not regress performance on TypedArrays and DataViews accesses.

Bug: v8:8015, v8:8178
Change-Id: Ia1d32f1b726754cea1e5793105d9423d84a6393a
Reviewed-on: https://chromium-review.googlesource.com/1246172Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56325}
      8ead5698
  5. 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
  7. 14 Sep, 2018 2 commits
    • 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
    • Benedikt Meurer's avatar
      [turbofan] Remove Truncation::Word64(). · 52fc1552
      Benedikt Meurer authored 
      This truncation doesn't have a proper meaning anyways and has never been
used inside the representation selection. For pointer fields we also
don't need to pass on a truncation anyways.

Bug: v8:8015
Change-Id: I5ff49e20b70fa70d6bcf7401a357cd7ad9f1a938
Reviewed-on: https://chromium-review.googlesource.com/1226870
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55885}
      52fc1552
  9. 11 Sep, 2018 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Insert unreachable node after unconditional deopt. · 3cfaca63
      Jaroslav Sevcik authored 
      This inserts unreachable node after uncoditional deopt in bit-to-word
conversion and wires it as an input to the dead-value.

This fixes a problem, where a floating  dead-value was inserted by a change
of bit-to-word (which always fails because bit cannot be converted to word).
Without the unrachable node (which this CL inserts in the effect chain after
deopt), the dead value was scheduled before the uncoditional deoptimization
and crash at runtime.

Unfortunately, I do not know how to construct a test that does not end up in
an infinite loop.

Bug: chromium:878805
Change-Id: Ia03060949f6a9b914807f5614fadcf2271911998
Reviewed-on: https://chromium-review.googlesource.com/1196663Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55770}
      3cfaca63
  11. 14 May, 2018 1 commit
  13. 28 Apr, 2018 1 commit
  15. 08 Feb, 2018 1 commit
  17. 23 Jan, 2018 1 commit
  19. 18 Dec, 2017 1 commit
  21. 05 Sep, 2017 1 commit
  23. 24 Jul, 2017 1 commit
  25. 22 May, 2017 1 commit
  27. 18 Apr, 2017 1 commit
  29. 08 Mar, 2017 1 commit
    • jarin's avatar
      [turbofan] Propagate minus-zero truncation in representation inference. · 18f169d4
      jarin authored 
      This introduces a new truncation bit for truncation of minus-zero to zero.

At the moment it is only used to handle the limit cases of deopt, such as the
one in the Google maps workload (see simplified version below), where the -q
(which is desugared to q * -1.0) currently deoptimizes because the result would
produce minus zero. To handle this situation, we exploit the knowledge that
righthand side of + cannot be -0, so even if lefthand side was -0, the result
would still be 0 (so the + operation cannot distinguish between left hand side
0 and -0).

function f(q) {
  q -= 4;
  return (-q) + q;
}

f(10);
f(10);
%OptimizeFunctionOnNextCall(f);
f(4);

Review-Url: https://codereview.chromium.org/2734253002
Cr-Commit-Position: refs/heads/master@{#43661}
      18f169d4
  31. 10 Jan, 2017 1 commit
  33. 03 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Improve representation selection for HeapObject checking. · 6322bf41
      bmeurer authored 
      For lowering CheckHeapObject, always report TaggedPointer representation
and let the RepresentationChanger come up with a reasonable conversion from
whatever input representation to TaggedPointer. This way we no longer insert
the useless ChangeSomethingToTagged and then check the result for HeapObject,
i.e. mostly reduces the amount of useless code being generated.

Note there are now two operators ChangeFloat64ToTaggedPointer and the old
ChangeFloat64ToTagged, because their semantics different wrt. the strength
reduction in the SimplifiedOperatorReducer.

Also set the output MachineRepresentation::kTaggedPointer properly in
SimplifiedLowering whenever we know that we produce a HeapObject.

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

Review-Url: https://codereview.chromium.org/2476593002
Cr-Commit-Position: refs/heads/master@{#40725}
      6322bf41
  35. 13 Oct, 2016 1 commit
  37. 12 Oct, 2016 1 commit
  39. 23 Sep, 2016 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Improve representation selection for Smi checking. · dfbb3db5
      Benedikt Meurer authored 
      Rename the high-level operators CheckTaggedSigned to CheckSmi and
CheckTaggedPointer to CheckHeapObject, to better match the naming
convention (i.e. ObjectIsSmi and CheckSmi, ObjectIsString and
CheckString, etc.).

For lowering CheckSmi, always report TaggedSigned representation
and let the RepresentationChanger come up with a reasonable conversion
from whatever input representation to TaggedSigned. This way we no
longer insert the useless ChangeSomethingToTagged and then Smi check
the result sequences, i.e. mostly reduces the amount of useless code
being generated. But we also observe a few performance improvements
on some crypto benchmarks.

This would enable us to avoid the Smi canonicalization when going from
Float64 to Tagged completely and thus match the representation selection
of Crankshaft in many areas (which might reduce the amount of
polymorphism until we fix our object model).

A follow-up CL will do the same for CheckHeapObject.

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

Review URL: https://codereview.chromium.org/2362173003 .

Cr-Commit-Position: refs/heads/master@{#39654}
      dfbb3db5
  41. 14 Sep, 2016 1 commit
  43. 08 Sep, 2016 1 commit
  45. 06 Sep, 2016 2 commits
  47. 01 Sep, 2016 1 commit
  49. 29 Aug, 2016 1 commit
    • mvstanton's avatar
      [Turbofan]: Use new MachineTypes in access-builder. · 56429fc1
      mvstanton authored 
      Introduced MachineType::TaggedSigned() and TaggedPointer().

The idea is to quit using the representational dimension of Type, and
instead encode this information in the MachineRepresentation (itself
lightly wrapped in MachineType, along with MachineSemantic).

There are three parts to the whole change:

1) Places that set the machine representation - constant nodes, loads nad
   stores, global object and native context specialization.

2) Places that propagate type/representation - this is representation
   inference (aka simplified lowering). At the end of this process we
   expect to have a MachineRepresentation for every node. An interesting
   part of this is phi merging.

3) Places that examine representation - WriteBarrier elimination does this.
   Currently it's looking at the Type representation dimension, but as
   a part of this change (or in a soon-to-follow change) it can simply
   examine the MachineRepresentation.

BUG=

Review-Url: https://codereview.chromium.org/2258073002
Cr-Commit-Position: refs/heads/master@{#38978}
      56429fc1
  51. 08 Aug, 2016 1 commit
  53. 03 Aug, 2016 1 commit
  55. 27 Jul, 2016 2 commits
  57. 21 Jul, 2016 2 commits
  59. 20 Jul, 2016 2 commits
  61. 13 Jul, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Extend undefined-to-number truncation to all oddballs. · 04b4df2c
      bmeurer authored 
      Extends the truncation and type checks for NumberOrUndefined in
representation selection and truncation analysis to deal with all
oddballs not just undefined. Also extend the type hints to always
report NumberOrOddball. This is necessary for the bitwise and shift
operators where NUMBER feedback actually means NUMBER or ODDBALL.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2149583002
Cr-Commit-Position: refs/heads/master@{#37711}
      04b4df2c
    • bmeurer's avatar
      [turbofan] Introduce CheckedUint32Div and CheckUint32Mod operators. · 15ebec03
      bmeurer authored 
      Checked integer division and modulus can be done more efficiently
if we know that the inputs are in Unsigned32 range.

Drive-by-fix: Replace the TypeCheckKind on NodeInfo by a proper
restriction type, and thread the feedback type through binary
Number operations similar to what we do for their speculative
versions. Also deal with Unsigned32 inputs for integer multiplication.

R=jarin@chromium.org
BUG=v8:4583,v8:5141

Review-Url: https://codereview.chromium.org/2149493002
Cr-Commit-Position: refs/heads/master@{#37703}
      15ebec03
  63. 12 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Allow non-speculative operators to consume feedback types. · b93cde37
      bmeurer authored 
      Turn the retyping pass of SimplifiedLowering into a proper phase, and
make it possible to propagate feedback types through non-speculative
operators. This defers the output representation selection to the
retyping phase, and checks that we don't mess up.

As a first user, we consume input type feedback for NumberAbs as well.
Long-term we can add all other operators to the mix.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2139203002
Cr-Commit-Position: refs/heads/master@{#37672}
      b93cde37
  65. 02 Jun, 2016 1 commit
    • jarin's avatar
      [turbofan] Initial version of number type feedback. · 216bcf9f
      jarin authored 
      This introduces optimized number operations based on type feedback.

Summary of changes:

1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
   there is suitable feedback. The speculative nodes are connected to both the
   effect chain and the control chain and they retain the eager frame state.

2. Simplified lowering now executes in three phases:
  a. Propagation phase computes truncations by traversing the graph from uses to
     definitions until checkpoint is reached. It also records type-check decisions
     for later typing phase, and computes representation.
  b. The typing phase computes more precise types base on the speculative types (and recomputes
     representation for affected nodes).
  c. The lowering phase performs lowering and inserts representation changes and/or checks.

3. Effect-control linearization lowers the checks to machine graphs.

Notes:

- SimplifiedLowering will be refactored to have handling of each operation one place and
  with clearer input/output protocol for each sub-phase. I would prefer to do this once
  we have more operations implemented, and the pattern is clearer.

- The check operations (Checked<A>To<B>) should have some flags that would affect
  the kind of truncations that they can handle. E.g., if we know that a node produces
  a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.

- In future, we want the typer to reuse the logic from OperationTyper.

BUG=v8:4583
LOG=n

Review-Url: https://codereview.chromium.org/1921563002
Cr-Commit-Position: refs/heads/master@{#36674}
      216bcf9f
  67. 22 Apr, 2016 1 commit