Skip to content

V
V8
Switch branch/tag
  1. 29 Jul, 2019 1 commit
  3. 25 Jul, 2019 1 commit
  5. 15 Jul, 2019 2 commits
  7. 12 Jul, 2019 2 commits
    • Nico Hartmann's avatar
      [turbofan] Push BigInt truncation over addition and heap constants · 99df710d
      Nico Hartmann authored 
      This change implements lowering of speculative BigInt addition as well as
BigInt heap constants to corresponding int64 versions, if they are used in
a context where the result is truncated to the least significant 64 bits
(e.g. using asUintN). The JSHeapBroker is extended to provide access to the
BigInt's least significant digit during concurrent compilation. The BigInt
context (required to introduce correct conversions) is recognized in the
RepresentationChanger by either the output type propagated downward or the
TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
may only be set by nodes that may potentially deopt (and sit in the effect
chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.

This CL contains a simple fix to prevent int64-lowered BigInts to flow into
state values as the deoptimizer cannot handle them yet. A more sophisticated
solution to allow the deoptimizer to materialize truncated BigInts will be
added in a following CL.

Bug: v8:9407
Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62665}
      99df710d
    • Georg Schmid's avatar
      [turbofan] Add optional runtime checks for range types · 2e82ead8
      Georg Schmid authored 
      This CL adds the --assert-types flag to d8, which is intended to
insert additional runtime checks after typed nodes, verifying the
validity of our typing rules. So far, only range types are checked.

Thanks to Neil Patil for suggesting something similar.

R=neis@chromium.org, tebbi@chromium.org

Change-Id: I5eb2c482235ec8cd07ee802ca7c12c86c2d3dc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678372
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62664}
      2e82ead8
  9. 11 Jul, 2019 1 commit
    • Mythri A's avatar
      Check that function was prepared before optimizing using manually · b086cb7b
      Mythri A authored 
      With lazy feedback allocation and bytecode flushing we need to call
%PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/
%OptimizeOsr. This cl:
1. Adds an additional state in pending optimized table to check if the
optimization was triggered manually.
2. Changes the compilation pipeline to delete the entry from pending
optimized table only if the optimization was triggered through
%OptimizeFunctionOnNextCall / %OptimizeOsr.
3. Adds a check to enforce %PrepareFunctionForOptimize was called.
4. Adds a new run-time flag to only check in the d8 test runner. We
don't want this check enabled in other cases like clusterfuzz that doesn't
ensure %PrepareFunctionForOptimize is called.

Bug: v8:8394, v8:8801, v8:9183
Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62653}
      b086cb7b
  11. 09 Jul, 2019 1 commit
  13. 25 Jun, 2019 1 commit
  15. 24 Jun, 2019 1 commit
  17. 19 Jun, 2019 1 commit
  19. 18 Jun, 2019 2 commits
  21. 14 Jun, 2019 2 commits
  23. 13 Jun, 2019 1 commit
  25. 12 Jun, 2019 1 commit
  27. 06 Jun, 2019 1 commit
  29. 31 May, 2019 1 commit
    • Mythri A's avatar
      [turbofan] Allow polymorphic inlining for Array push / pop / shift · 3e90eee9
      Mythri A authored 
      Array push / pop / shift were inlined if the elements kind of the
receiver maps is the same. This cl extends it by inlining these
builtins even when the receiver maps have different elements kinds.
It still limits it to only fast elements kinds. This is required to
prevent regressions in deltablue when lazy feedback allocation is
enabled. With lazy feedback allocation we may see polymorphic
feedback more often, since we don't have allocation site feedback
till the feedback vectors are allocated.

Bug: v8:9078
Change-Id: Id4a7b84be6305b125913b6ce0fb4f3eb3e3b15ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632239
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61949}
      3e90eee9
  31. 28 May, 2019 1 commit
  33. 27 May, 2019 1 commit
    • Georg Schmid's avatar
      Reland "Make LoadElimination aware of const fields (Part 2; stores)" · 85f257f4
      Georg Schmid authored 
      This is a reland of e588ff10

The only change over the original CL is found in JSCreateLowering::AllocateFastLiteral. We now guard against boilerplate values for unboxed double fields that *look* like legitimate initial values, but should really be kHoleNanInt64 instead.

The underlying problem certainly existed before, but an invariant added to LoadElimination in this CL caused a Chromium layout test to fail. The change in this reland is therefore a workaround, the root cause remains to be fixed. Specifically, we find that a pointer to the undefined value oddball is sometimes reinterpreted as a double and assigned as a boilerplate value. @jarin suspects that this stems from in-place map updates.

Original change's description:
> Make LoadElimination aware of const fields (Part 2; stores)
>
> Adds const information to store field accesses and uses it in load elimination
>
> Change-Id: I00765c854c95c955dabd78557463267b95f75eef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1611543
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Georg Schmid <gsps@google.com>
> Cr-Commit-Position: refs/heads/master@{#61796}

Change-Id: Ie388754890024a3ca7d10c9d4d7391442655b426
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630676Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#61838}
      85f257f4
  35. 24 May, 2019 1 commit
  37. 23 May, 2019 2 commits
  39. 22 May, 2019 1 commit
  41. 20 May, 2019 4 commits
  43. 16 May, 2019 1 commit
  45. 15 May, 2019 2 commits
  47. 14 May, 2019 1 commit
  49. 13 May, 2019 2 commits
  51. 08 May, 2019 2 commits
  53. 06 May, 2019 1 commit
  55. 03 May, 2019 2 commits