Skip to content

V
V8
Switch branch/tag
  1. 12 Jan, 2021 1 commit
  3. 11 Jan, 2021 26 commits
  5. 10 Jan, 2021 1 commit
  7. 09 Jan, 2021 5 commits
  9. 08 Jan, 2021 7 commits
    • Georgia Kouveli's avatar
      [arm64] Use static_cast instead of reinterpret_cast in CFI code · b3330e95
      Georgia Kouveli authored 
      In a couple of places we cast between uintptr_t and uint64_t with a
reinterpret_cast. While this is correct when these types are aliased
to the same type, if they are defined to be different integral types
(while still of the same size), reinterpet_cast won't work.

Change-Id: I6e935c6c263d8df16f88659ac285faeb5e073add
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614678Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#71988}
      b3330e95
    • Seth Brenith's avatar
      [interpreter] Include Star lookahead for more bytecodes · 0d30fac2
      Seth Brenith authored 
      I made some temporary changes in BytecodeArrayWriter to log counts of
how often each pair of bytecodes is adjacent. In data I collected on a
Facebook page with those changes enabled, I noticed that the following
bytecodes were commonly followed by Star, but do not appear in
IsStarLookahead.

LdaImmutableCurrentContextSlot:
  4.4% of all instructions, 66% chance to be followed by Star
CreateClosure:
  3.9% of all instructions, 57% chance to be followed by Star
LdaImmutableContextSlot:
  1.7% of all instructions, 95% chance to be followed by Star
CreateObjectLiteral:
  1.4% of all instructions, 92% chance to be followed by Star
CreateArrayLiteral:
  1.4% of all instructions, 99% chance to be followed by Star
ThrowReferenceErrorIfHole:
  0.7% of all instructions, 100% chance to be followed by Star
GetTemplateObject:
  0.6% of all instructions, 100% chance to be followed by Star
CreateEmptyArrayLiteral:
  0.4% of all instructions, 87% chance to be followed by Star
CreateEmptyObjectLiteral:
  0.2% of all instructions, 79% chance to be followed by Star

I cross-referenced this list with data from google.com and youtube.com
(the top two sites according to Alexa), and found that CreateClosure and
CreateEmpty*Literal are not likely followed by Star on those sites.
Without those three, I suggest that the following bytecode handlers
would likely benefit from Star lookahead:

LdaImmutableCurrentContextSlot
LdaImmutableContextSlot
CreateObjectLiteral
CreateArrayLiteral
ThrowReferenceErrorIfHole
GetTemplateObject

I also ran Octane with --noopt and got the following results.

Name               Median change (95% CI)    U test result
-----------------  ------------------------  -------------------
Richards           +1.02% to +3.28%          improved  p=1.8e-05
DeltaBlue          -1.47% to +0.12%          regressed p=0.05
Crypto             -1.11% to +0.93%          inconclusive
RayTrace           -1.10% to +0.48%          inconclusive
EarleyBoyer        -0.25% to +1.29%          inconclusive
RegExp             -1.46% to +0.08%          inconclusive
Splay              -1.10% to +0.03%          inconclusive
SplayLatency       +0.13% to +0.92%          improved  p=5.8e-05
NavierStokes       -0.22% to +1.24%          inconclusive
PdfJS              -0.69% to +1.04%          inconclusive
Mandreel           -0.66% to +0.66%          inconclusive
MandreelLatency    +0.32% to +1.77%          improved  p=0.00024
Gameboy            -1.13% to +0.38%          inconclusive
CodeLoad           -0.27% to +0.43%          inconclusive
Box2D              -0.53% to +0.82%          inconclusive
zlib               -0.19% to +0.19%          inconclusive
Typescript         -0.23% to +0.59%          inconclusive
Score (version 9)  -0.18% to +0.68%          inconclusive

I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue
agrees that all of the selected bytecodes are likely to precede Star,
but overall I think this change is more benefit than harm.

Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71987}
      0d30fac2
    • Milad Fa's avatar
      PPC/s390: [wasm-simd][liftoff][x64] Prototype load lane · e4675193
      Milad Fa authored 
      Port 5af79398

Original Commit Message:

    Prototype load lane instructions on Liftoff, only for x64.

R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: If9429791139d08a3dd7548220b4eb28e99d6fc7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618241Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71986}
      e4675193
    • Mythri A's avatar
      Disable bytecode flushing once we toggle coverage mode. · 8aa6b15f
      Mythri A authored 
      Changing coverage mode generated different bytecode in some cases.
Hence it is not safe to flush bytecode once we toggle coverage mode.

Bug: chromium:1147917
Change-Id: I9e640aeaec664d3d4a4aaedf809c568e9ad924fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615020
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71985}
      8aa6b15f
    • Jakob Kummerow's avatar
      Reland "[wasm-gc] Liftoff support part 5: i31" · 432c0a78
      Jakob Kummerow authored 
      This is a reland of a3ce2f6d
(No changes; was reverted because a dependency was reverted.)

Original change's description:
> [wasm-gc] Liftoff support part 5: i31
>
> This implements support for i31.get_s and i31.get_u.
>
> Bug: v8:7748
> Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71808}

Bug: v8:7748
Change-Id: Id8e66cab285d2a36fcd712b92a522e83dea93193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617089Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71984}
      432c0a78
    • Junliang Yan's avatar
      s390x: [liftoff] implement stack frame handling · 2651820e
      Junliang Yan authored 
      Change-Id: I68ef1a97ac857106e014d561be3d7e845ec9fbdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618280Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71983}
      2651820e
    • Santiago Aboy Solanes's avatar
      [compiler] Make StringRef::GetFirstChar() return an optional value · 740d94be
      Santiago Aboy Solanes authored 
      Follow-up that continues to make StringRefs's methods return optional
values.

Bug: v8:7790
Change-Id: I34f907810747216b047a3da8db035cf4f62728c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615162Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71982}
      740d94be