Skip to content

V
V8
Switch branch/tag
  1. 18 May, 2018 1 commit
  3. 30 Apr, 2018 1 commit
  5. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  7. 13 Apr, 2018 1 commit
  9. 16 Mar, 2018 1 commit
  11. 21 Feb, 2018 1 commit
  13. 13 Feb, 2018 1 commit
  15. 02 Feb, 2018 1 commit
  17. 22 Jan, 2018 1 commit
  19. 16 Jan, 2018 1 commit
  21. 20 Dec, 2017 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Preparation for padding of arguments" · f6879033
      Georgia Kouveli authored 
      This is a reland of bcf11729

The test was timing out in no snapshot builds, as each CodeAssemblerTester
creates a new Context. Reduced the random iterations significantly.

Original change's description:
> [arm64] Preparation for padding of arguments
>
> As part of JSSP removal, we need to align the arguments passed to functions
> on the stack, by adding a padding slot when the total number of arguments
> is odd.
>
> This patch introduces the kPadArguments flag (which is currently set to
> false for all architectures), which will control padding of arguments in
> architecture-independent parts of the code (deoptimizer, instruction
> selector).
>
> It also adds some executable tests for tail calls with various stack
> parameter counts on the caller and callee sides.
>
> This will be turned on for arm64 together with arm64-specific changes to
> the code generator, the MacroAsembler and the builtins, in a later patch.
>
> Bug: v8:6644
> Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
> Reviewed-on: https://chromium-review.googlesource.com/806554
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50134}

TBR=jarin@chromium.org

Bug: v8:6644
Change-Id: I795877ed9791e126ffac6841dbbb65189e95d207
Reviewed-on: https://chromium-review.googlesource.com/833046
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50238}
      f6879033
  23. 16 Dec, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[arm64] Preparation for padding of arguments" · fb8efb12
      Michael Achenbach authored 
      This reverts commit bcf11729.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/16791

The test cctest/test-run-tail-calls/FuzzStackParamCount hangs on
the nosnap debug bot and times out.

Original change's description:
> [arm64] Preparation for padding of arguments
> 
> As part of JSSP removal, we need to align the arguments passed to functions
> on the stack, by adding a padding slot when the total number of arguments
> is odd.
> 
> This patch introduces the kPadArguments flag (which is currently set to
> false for all architectures), which will control padding of arguments in
> architecture-independent parts of the code (deoptimizer, instruction
> selector).
> 
> It also adds some executable tests for tail calls with various stack
> parameter counts on the caller and callee sides.
> 
> This will be turned on for arm64 together with arm64-specific changes to
> the code generator, the MacroAsembler and the builtins, in a later patch.
> 
> Bug: v8:6644
> Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
> Reviewed-on: https://chromium-review.googlesource.com/806554
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50134}

TBR=rmcilroy@chromium.org,jarin@chromium.org,georgia.kouveli@arm.com

Change-Id: Iff4d7da418204834822842b160eacb8980058172
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6644
Reviewed-on: https://chromium-review.googlesource.com/830847Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50144}
      fb8efb12
  25. 15 Dec, 2017 1 commit
    • Georgia Kouveli's avatar
      [arm64] Preparation for padding of arguments · bcf11729
      Georgia Kouveli authored 
      As part of JSSP removal, we need to align the arguments passed to functions
on the stack, by adding a padding slot when the total number of arguments
is odd.

This patch introduces the kPadArguments flag (which is currently set to
false for all architectures), which will control padding of arguments in
architecture-independent parts of the code (deoptimizer, instruction
selector).

It also adds some executable tests for tail calls with various stack
parameter counts on the caller and callee sides.

This will be turned on for arm64 together with arm64-specific changes to
the code generator, the MacroAsembler and the builtins, in a later patch.

Bug: v8:6644
Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08
Reviewed-on: https://chromium-review.googlesource.com/806554
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50134}
      bcf11729
  27. 22 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      Allow move semantics on Labels · eeb32224
      Clemens Hammacher authored 
      The Label class currently allows to be copied on all platforms except
for arm64, where it can not be copied or moved.
This allows too much though:
Copying a label even on another platform than arm64 might fail if the
label was linked already, because only one of the copies will be bound
later, and the other will fire a DCHECK error in its destructor.

This CL changes the restriction to never allow to copy construct or
assign a Label, but allow move construction and move assignment on all
platforms except arm64.
This will allow to place Labels in containers, as will be done in
Liftoff (except for arm64, where it still needs to be allocated on the
heap).

R=mstarzinger@chromium.org

Bug: v8:6600
Change-Id: Ic1234c2d233317eed6a3d537c13faed2c701fe13
Reviewed-on: https://chromium-review.googlesource.com/783190
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49570}
      eeb32224
  29. 18 Oct, 2017 1 commit
  31. 13 Oct, 2017 3 commits
  33. 13 Sep, 2017 1 commit
  35. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored 
      Up to now, each architecture defined all Register types as structs,
with lots of redundancy. An often found comment noted that they cannot
be classes due to initialization order problems. As these problems are
gone with C++11 constexpr constants, I now tried making Registers
classes again.
All register types now inherit from RegisterBase, which provides a
default set of methods and named constructors (like ::from_code,
code(), bit(), is_valid(), ...).
This design allows to guarantee an interesting property: Each register
is either valid, or it's the no_reg register. There are no other
invalid registers. This is guaranteed statically by the constexpr
constructor, and dynamically by ::from_code.

I decided to disallow the default constructor completely, so instead of
"Register reg;" you now need "Register reg = no_reg;". This makes
explicit how the Register is initialized.

I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
Overall, code got much more compact and more safe. In theory, it should
also increase performance (since the is_valid() check is simpler), but
this is probably not measurable.

R=mstarzinger@chromium.org

Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  37. 04 Sep, 2017 1 commit
  39. 17 Aug, 2017 1 commit
  41. 16 Aug, 2017 1 commit
  43. 02 Aug, 2017 1 commit
  45. 01 Aug, 2017 1 commit
  47. 28 Jul, 2017 1 commit
    • sreten.kovacevic's avatar
      MIPS[64]: Port `[arm] Introduce UseScratchRegisterScope` · 3eb4de34
      sreten.kovacevic authored 
      Add UseScratchRegisterScope for MIPS and use it instead of using at register directly.

Original commit message:
`Introduce a stripped down version of UseScratchRegisterScope for ARM and use it
inside the assembler and macro-assembler. At the exception of the Call
instructions, we now use this scope instead of using the ip register
directly. This is inspired from how the ARM64 backend works.

In general, the benefit of doing this is we can catch cases where ip is being
used both by the caller and by the assembler. But more specifically, TurboFan
reserves r9 as an extra scratch register because ip can already be used by the
assembler. With this utility, we can isolate the cases in the code generator
which need an extra register and potentially fix them, allowing us to give r9
back to the register allocator.

This patch uncovered places in the assembler where we were using ip
unconditionally when we could have re-used the destination register instead.`

Bug: 
Change-Id: I1a35c1661579882801605337abfc95f75b47f052
Reviewed-on: https://chromium-review.googlesource.com/574923
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: 's avatarIvica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46963}
      3eb4de34
  49. 11 Jul, 2017 1 commit
  51. 10 Jul, 2017 2 commits
  53. 05 Jul, 2017 1 commit
  55. 28 Jun, 2017 2 commits
  57. 20 Jun, 2017 1 commit
  59. 01 Jun, 2017 1 commit
  61. 31 May, 2017 1 commit
    • neis's avatar
      [compiler] Delay allocation of code-embedded heap numbers. · 659e8f7b
      neis authored 
      Instead of allocating and embedding certain heap numbers into the code
during code assembly, emit dummies but record the allocation requests.
Later then, in Assembler::GetCode, allocate the heap numbers and patch
the code by replacing the dummies with the actual objects. The
RelocInfos for the embedded objects are already recorded correctly when
emitting the dummies.

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

Review-Url: https://codereview.chromium.org/2900683002
Cr-Commit-Position: refs/heads/master@{#45635}
      659e8f7b
  63. 10 May, 2017 1 commit
  65. 28 Apr, 2017 1 commit
  67. 20 Apr, 2017 1 commit
  69. 12 Apr, 2017 1 commit
  71. 27 Mar, 2017 1 commit