Skip to content

V
V8
Switch branch/tag
  1. 29 Aug, 2018 1 commit
  3. 28 Aug, 2018 1 commit
  5. 23 Aug, 2018 3 commits
  7. 22 Aug, 2018 2 commits
  9. 21 Aug, 2018 1 commit
    • Jakob Gruber's avatar
      Revert "[x64] Apply rip-relative call/jump for OFF_HEAP_TARGET" · dcc09b60
      Jakob Gruber authored 
      This reverts commit ad5b7365.

Reason for revert: https://crbug.com/875678

Original change's description:
> [x64] Apply rip-relative call/jump for OFF_HEAP_TARGET
>
> Merge rip-relative loading and call/jump into one instruction for
> OFF_HEAP_TARGET call/jump. For example,
>
>   REX.W movq r10,[rip+#disp]
>   call r10
>
> turns into:
>
>   call [rip+#disp]
>
> Change-Id: I17e115d054b4b352bdaf8eba2e6ac4054bbedaca
> Reviewed-on: https://chromium-review.googlesource.com/1172152
> Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55150}

TBR=sigurds@chromium.org,jgruber@chromium.org,shiyu.zhang@intel.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: chromium:875678
Change-Id: I5a9dd6e29cc53566d681864f7e275a70ccdcb0cb
Reviewed-on: https://chromium-review.googlesource.com/1183164
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55255}
      dcc09b60
  11. 17 Aug, 2018 1 commit
  13. 16 Aug, 2018 2 commits
  15. 14 Aug, 2018 2 commits
    • 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
  17. 13 Aug, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · c46915b9
      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: I296170b828c2ccc1c317ed37840b564aa14cdec2
Reviewed-on: https://chromium-review.googlesource.com/1172777
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55099}
      c46915b9
  19. 08 Aug, 2018 5 commits
  21. 02 Aug, 2018 1 commit
  23. 30 Jul, 2018 1 commit
    • jgruber's avatar
      [builtins,x64] More information about root-relative accesses · 1bef7d21
      jgruber authored 
      When disassembling code (in particular embedded builtins), try to
print better information about root-relative accesses. For example:

 REX.W movq rdx,[r13+0x548]
 REX.W movq rax,[r13+0x10a8]

turns into

 REX.W movq rdx,[r13+0x548] (root (0x1ff420d0ccd9 <FixedArray[1672]>))
 REX.W movq rax,[r13+0x10a8] (external reference (check_object_type))

This is a band-aid solution until we come up with something better. It
does not understand multi-instruction sequences (such as loads from
the builtins constants table), assumes every kRootRegister-relative
access is actually root-relative (i.e. the register is not initialized
to some other value), and is limited to a particular instruction
pattern.

Bug: v8:6666,v8:7969
Change-Id: I35af92e8233c9bb0f2ad6ba0e86bd0ab69177205
Reviewed-on: https://chromium-review.googlesource.com/1146806
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54777}
      1bef7d21
  25. 26 Jul, 2018 2 commits
  27. 24 Jul, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored 
      This is a reland of a462a785

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
    • jgruber's avatar
      [builtins] Wipe off-heap targets for serialization · eefb5de4
      jgruber authored 
      For reproducible snapshots, we need to wipe target addresses.

Bug: v8:6666
Change-Id: Id30c3f92c342ae85e9dce677439a6f05182482cd
Reviewed-on: https://chromium-review.googlesource.com/1146653
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54626}
      eefb5de4
  29. 23 Jul, 2018 1 commit
  31. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored 
      This reverts commit a462a785.

Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored 
      For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.

This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.

Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  33. 19 Jul, 2018 1 commit
  35. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored 
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
builtins to embedded builtins. To make this work, the code range size is
limited to 32MB on arm during mksnapshot, which ensures that all builtin
to builtin offsets for jumps/calls fit into the B/BL immediate. At code
generation time, we put a placeholder into the instruction offset which
we resolve to the right code object when the code is copied to the heap.
We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
The relocation mode RELATIVE_CODE_TARGET should never appear after
generating the snapshot.

We modify the target_address/set_target_address methods of RelocInfo
such that they return the absolute target addresses for pc-relative B/BL
instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
the same way as code targets. This, however, only matters during
snapshot creation time, and production code never contains
RELATIVE_CODE_TARGET relocations.

Bug: v8:6666
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  37. 06 Jul, 2018 1 commit
  39. 05 Jul, 2018 1 commit
  41. 03 Jul, 2018 2 commits
  43. 26 Jun, 2018 6 commits
    • Georg Neis's avatar
      Reland "Reland "Introduce MutableHeapNumber class."" · f1c79e02
      Georg Neis authored 
      This is a reland of f0bcbc90.
A few casts were still wrong.

Original change's description:
> Reland "Introduce MutableHeapNumber class."
>
> This is a reland of 40ac6b18, which
> was incorrect due to a bad merge.
>
> Original change's description:
> > Introduce MutableHeapNumber class.
> >
> > V8 knows heap numbers and mutable heap numbers. They have
> > difference instance types, but in C++ code we've used the
> > same class for both (HeapNumber). Confusingly, however,
> > IsHeapNumber would return false for mutable heap numbers,
> > while HeapNumber::cast would succeed.
> >
> > This CL adds a separate class MutableHeapNumber and
> > eliminates the confusing behavior.
> >
[...]
> TBR=bmeurer@chromium.org
> TBR=ulan@chromium.org
>
> Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
> Reviewed-on: https://chromium-review.googlesource.com/1114539
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54022}

Change-Id: I19a33da4b6abcd445b528a84d4f56ba1964d337b
Reviewed-on: https://chromium-review.googlesource.com/1114100
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54027}
      f1c79e02
    • Michael Starzinger's avatar
      [wasm] Remove obsolete code specialization support. · 8ca3d065
      Michael Starzinger authored 
      R=clemensh@chromium.org

Change-Id: Id8a0849d3456be1062a065a23f51bac250de4f7d
Reviewed-on: https://chromium-review.googlesource.com/1107936Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54026}
      8ca3d065
    • Georg Neis's avatar
      Revert "Reland "Introduce MutableHeapNumber class."" · 722dfb70
      Georg Neis authored 
      This reverts commit f0bcbc90.

Reason for revert: Still failing bots.

Original change's description:
> Reland "Introduce MutableHeapNumber class."
> 
> This is a reland of 40ac6b18, which
> was incorrect due to a bad merge.
> 
> Original change's description:
> > Introduce MutableHeapNumber class.
> >
> > V8 knows heap numbers and mutable heap numbers. They have
> > difference instance types, but in C++ code we've used the
> > same class for both (HeapNumber). Confusingly, however,
> > IsHeapNumber would return false for mutable heap numbers,
> > while HeapNumber::cast would succeed.
> >
> > This CL adds a separate class MutableHeapNumber and
> > eliminates the confusing behavior.
> >
> > TBR=bmeurer@chromium.org
> >
> > Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
> > Reviewed-on: https://chromium-review.googlesource.com/1113544
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#54012}
> 
> TBR=bmeurer@chromium.org
> TBR=ulanchromium.org
> 
> Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
> Reviewed-on: https://chromium-review.googlesource.com/1114539
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54022}

TBR=ulan@chromium.org,jarin@chromium.org,neis@chromium.org,bmeurer@chromium.org

Change-Id: I99c226e95dfb0b913903cc83193f6e51de8c1b47
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1114099Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54024}
      722dfb70
    • Sigurd Schneider's avatar
      [turbofan] Support kRootRegisterBias on all platforms · ba39d635
      Sigurd Schneider authored 
      We had a kRootRegisterBias on x64 before. This CL ports the feature to
all other platforms as well. The root register bias is helpful to adjust
the value of the root register, which allows to better utilize signed
immediate offset constants in load instructions.

We currently use a separate add instruction to add kRootRegisterBias
in the code that initializes the root register. This could be improved
by adding a custom relocation mode ensuring that instead of the root
address, the root address plus the bias is inserted (and in this way
the add instruction can be omitted).

Bug: v8:6666
Change-Id: I55cf02ab85d11e3c6d0d83a8f7905dbf924890f1
Reviewed-on: https://chromium-review.googlesource.com/1113539
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54023}
      ba39d635
    • Georg Neis's avatar
      Reland "Introduce MutableHeapNumber class." · f0bcbc90
      Georg Neis authored 
      This is a reland of 40ac6b18, which
was incorrect due to a bad merge.

Original change's description:
> Introduce MutableHeapNumber class.
>
> V8 knows heap numbers and mutable heap numbers. They have
> difference instance types, but in C++ code we've used the
> same class for both (HeapNumber). Confusingly, however,
> IsHeapNumber would return false for mutable heap numbers,
> while HeapNumber::cast would succeed.
>
> This CL adds a separate class MutableHeapNumber and
> eliminates the confusing behavior.
>
> TBR=bmeurer@chromium.org
>
> Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
> Reviewed-on: https://chromium-review.googlesource.com/1113544
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54012}

TBR=bmeurer@chromium.org
TBR=ulanchromium.org

Change-Id: I3af1014c949821dfac0754a3e48c65ce1bad1ad1
Reviewed-on: https://chromium-review.googlesource.com/1114539Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54022}
      f0bcbc90
    • Yang Guo's avatar
      Revert "Introduce MutableHeapNumber class." · 983456f5
      Yang Guo authored 
      This reverts commit 40ac6b18.

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

Original change's description:
> Introduce MutableHeapNumber class.
> 
> V8 knows heap numbers and mutable heap numbers. They have
> difference instance types, but in C++ code we've used the
> same class for both (HeapNumber). Confusingly, however,
> IsHeapNumber would return false for mutable heap numbers,
> while HeapNumber::cast would succeed.
> 
> This CL adds a separate class MutableHeapNumber and
> eliminates the confusing behavior.
> 
> TBR=bmeurer@chromium.org
> 
> Change-Id: Id894d177c7fe8cc3f451be80c273b50daee91378
> Reviewed-on: https://chromium-review.googlesource.com/1113544
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54012}

TBR=ulan@chromium.org,jarin@chromium.org,neis@chromium.org,bmeurer@chromium.org

Change-Id: I358a822f20b9110def968e69463a753a2a32c68c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/1114538Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54013}
      983456f5