Skip to content

V
V8
Switch branch/tag
  1. 22 Jun, 2018 1 commit
  3. 21 Jun, 2018 1 commit
  5. 18 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Make CallInterfaceDescriptor isolate-independent · 3cb376dc
      Clemens Hammacher authored 
      Currently each isolate stores its own array of
{CallInterfaceDescriptorData}. This array has size 173, and each entry
has 40 bytes. That's already 7kB per isolate.
Additionally, each {CallInterfaceDescriptorData} allocates two
heap-allocated arrays, which probably add up to more than the static
size of the {CallInterfaceDescriptorData}. Note that all the
{CallInterfaceDescriptorData} instances are initialized eagerly on
isolate creation.

Since {CallInterfaceDescriptor} is totally isolate independent itself,
this CL refactors the current design to avoid a copy of them per
isolate, and instead shares them process-wide. Still, we need to free
the allocated heap arrays when the last isolate dies to avoid leaks.
This can probably be refactored later by statically initializing more
and avoiding the heap allocations all together.

This refactoring will also allow us to use {CallInterfaceDescriptor}s
from wasm background compilation threads, which are not bound to any
isolate.

R=mstarzinger@chromium.org, titzer@chromium.org

Bug: v8:6600
Change-Id: If8625b89951eec8fa8986b49a5c166e874a72494
Reviewed-on: https://chromium-review.googlesource.com/1100879
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53803}
      3cb376dc
    • Michael Starzinger's avatar
      [turbofan] Remove obsolete Linkage::GetAllocateCallDescriptor. · 8d82cddb
      Michael Starzinger authored 
      R=ishell@chromium.org

Change-Id: I84288cc16297dbe33adddbdf08b689db95d0fc04
Reviewed-on: https://chromium-review.googlesource.com/1104164Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53786}
      8d82cddb
  7. 14 Jun, 2018 2 commits
  9. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored 
      Stubs and builtins are very similar. The main differences are that
stubs can be parameterized and may be generated at runtime, whereas
builtins are generated at mksnapshot-time and shipped with the snapshot
(or embedded into the binary).

My main motivation for these conversions is that we can generate
faster calls and jumps to (embedded) builtins callees from (embedded)
builtin callers. Instead of going through the builtins constants table
indirection, we can simply do a pc-relative call/jump.

This also unlocks other refactorings, e.g. removal of
CallRuntimeDelayed.

TBR=mlippautz@chromium.org

Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  11. 03 May, 2018 1 commit
  13. 17 Apr, 2018 1 commit
  15. 16 Apr, 2018 1 commit
  17. 04 Apr, 2018 1 commit
  19. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored 
      Moves generation of speculation poison to be based on the PC target vs the
actual PC being executed. The speculation poison is generated in the prologue
of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
The result is stored in a known register, which can then be read using the
SpeculationPoison machine node.

Currently we need to ensure the SpeculationPoison node is scheduled right after
the code prologue so that the poison register doesn't get clobbered. This is
currently not verified, however it's only use is in RawMachineAssembler where
it is manually scheduled early.

The Ignition bytecode handlers are updated to use this speculation poison
rather than one generated by comparing the target bytecode.

BUG=chromium:798964

Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  21. 16 Jan, 2018 1 commit
  23. 12 Jan, 2018 1 commit
  25. 21 Dec, 2017 1 commit
    • Georgia Kouveli's avatar
      [arm64] Pad function arguments. · 5d10735e
      Georgia Kouveli authored 
      This patch updates the instruction selector and code generator to pad arguments
for arm64 and drop an even number of slots when dropping the arguments. It also
updates the builtins that handle arguments. These changes need to be made at
the same time.

It also adds some tests for forwarding varargs, as this was affected by the
builtin changes and the existing tests did not catch all issues.

Bug: v8:6644
Change-Id: I81318d1d1c9ab2568f84f2bb868d2a2d4cb56053
Reviewed-on: https://chromium-review.googlesource.com/829933
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50259}
      5d10735e
  27. 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
  29. 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
  31. 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
  33. 12 Dec, 2017 1 commit
    • Andreas Haas's avatar
      Reland [turbofan] Implement on-stack returns (Intel) · bd732f7d
      Andreas Haas authored 
      The original CL introduced a test which uses a random number generator.
I disable the test for now, which is okay because this CL adds to a
work-in-progress feature anyways, and I will fix the problem in another
CL.

Original description:
Add the ability to return (multiple) return values on the stack:

- Extend stack frames with a new buffer region for return slots.
  This region is located at the end of a caller's frame such that
  its slots can be indexed as caller frame slots in a callee
  (located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
  reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.

So far, only ia32 and x64 are implemented.

Change-Id: I8b03fc4e53946daaa0e14a34603f4824a04fad7e
Reviewed-on: https://chromium-review.googlesource.com/819557Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50031}
      bd732f7d
  35. 11 Dec, 2017 2 commits
    • Andreas Haas's avatar
      Revert "[turbofan] Implement on-stack returns (Intel)" · 943ccb98
      Andreas Haas authored 
      This reverts commit 1e49864f.

Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0

Original change's description:
> [turbofan] Implement on-stack returns (Intel)
> 
> Add the ability to return (multiple) return values on the stack:
> 
> - Extend stack frames with a new buffer region for return slots.
>   This region is located at the end of a caller's frame such that
>   its slots can be indexed as caller frame slots in a callee
>   (located beyond its parameters) and assigned return values.
> - Adjust stack frame constructon and deconstruction accordingly.
> - Extend linkage computation to support register plus stack returns.
> - Reserve return slots in caller frame when respective calls occur.
> - Introduce and generate architecture instructions ('peek') for
>   reading back results from return slots in the caller.
> - Aggressive tests.
> - Some minor clean-up.
> 
> So far, only ia32 and x64 are implemented.
> 
> Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
> Reviewed-on: https://chromium-review.googlesource.com/766371
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49994}

TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org

Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/819637Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50000}
      943ccb98
    • Andreas Haas's avatar
      [turbofan] Implement on-stack returns (Intel) · 1e49864f
      Andreas Haas authored 
      Add the ability to return (multiple) return values on the stack:

- Extend stack frames with a new buffer region for return slots.
  This region is located at the end of a caller's frame such that
  its slots can be indexed as caller frame slots in a callee
  (located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
  reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.

So far, only ia32 and x64 are implemented.

Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
Reviewed-on: https://chromium-review.googlesource.com/766371
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49994}
      1e49864f
  37. 29 Nov, 2017 1 commit
  39. 21 Nov, 2017 1 commit
  41. 25 Sep, 2017 1 commit
  43. 22 Sep, 2017 1 commit
  45. 04 Sep, 2017 1 commit
  47. 24 Aug, 2017 1 commit
  49. 01 Aug, 2017 1 commit
  51. 20 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [compiler] Allow for interfaces without context · e9d728d0
      Clemens Hammacher authored 
      Especially in wasm, many builtins don't actually need a context
parameter. We currently pass Smi::kZero instead. This CL allows to
generate a CallDescriptor for calling stubs without passing a context,
resulting in reduced compile time and code size, and increased
performance when executing these builtins.

We were calling the ThrowWasm* functions without passing a context
anyway (directly from code-generator-<arch>.h). With this change, we
will also call the StackCheck builtin without passing a (null) context.
This saves two bytes of code in each function plus each loop, and also
slightly reduces compile time (very noisy, but statistically
significant).

Drive-by: Use NoContextConstant instead of SmiConstant(Smi::kZero).

R=mstarzinger@chromium.org, ahaas@chromium.org

Change-Id: If794cc4c262a9cca8d29a68010803c01a2eef4a3
Reviewed-on: https://chromium-review.googlesource.com/541423Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46044}
      e9d728d0
  53. 03 Nov, 2016 1 commit
  55. 17 Oct, 2016 1 commit
  57. 20 Sep, 2016 1 commit
  59. 19 Aug, 2016 1 commit
  61. 02 Aug, 2016 1 commit
  63. 27 Jul, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Implement OSR graph construction from bytecode. · 1314406c
      mstarzinger authored 
      This implements graph construction for entry via on-stack replacement
within the {BytecodeGraphBuilder}. Entry points are at loop headers
similar to previous OSR implementations. All interpreter registers are
addressable via {OsrValue} nodes in the graph. Currently we rely on
{OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
targets of back edges).

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

Review-Url: https://codereview.chromium.org/2171083004
Cr-Commit-Position: refs/heads/master@{#38083}
      1314406c
  65. 22 Jul, 2016 1 commit
    • yangguo's avatar
      [debug] use catch prediction flag for promise rejections. · 6d0a4202
      yangguo authored 
      This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.

BUG=v8:5167

Review-Url: https://codereview.chromium.org/2161263003
Cr-Commit-Position: refs/heads/master@{#37966}
      6d0a4202
  67. 12 Jul, 2016 1 commit
    • danno's avatar
      [turbofan] Robustify tail parameter stack size computations · e92e9118
      danno authored 
      This CL separates the check whether something is tail-callable from
the computation of the size of the stack parameters that a function
takes.

In order to track this precisely, the stack parameter size calculation
uses the recently landed MachineType information that's embedded
in return and parameter value LinkageLocations.

Review-Url: https://codereview.chromium.org/2121753002
Cr-Commit-Position: refs/heads/master@{#37668}
      e92e9118
  69. 11 Jul, 2016 1 commit
    • danno's avatar
      [turbofan] Add MachineType to LinkageLocation · 3e2085eb
      danno authored 
      By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.

As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.

R=titzer@chromium.org, bmeurer@chromium.org
LOG=N

Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
      3e2085eb
  71. 01 Jul, 2016 1 commit
    • danno's avatar
      [turbofan]: Support using push instructions for setting up tail call parameters · bd0d9e7d
      danno authored 
      This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.

Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}
      bd0d9e7d
  73. 02 Jun, 2016 1 commit