1. 29 Mar, 2019 1 commit
  2. 28 Jan, 2019 1 commit
  3. 25 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Support anyref stack parameters · 258371bd
      Andreas Haas authored
      Anyref parameters can exist across GC runs. Therefore the GC has to
      know where anyref parameters are on the stack so that it can mark them
      in its marking phase, and update them in the compaction phase.
      
      Already in a previous CL we grouped all anyref parameters so that they
      can be found more easily in a stack frame, see
      https://crrev.com/c/1371827. In this CL we implement the stack scanning
      itself.
      
      Note that anyref parameters are not scanned while iterating over the
      caller's frame (to which they actually belong), but while iterating
      over the callee's frame. The reason is that with tail-calls, only the
      callee knows how many tagged stack parameters (aka anyref parameters)
      there are.
      
      R=mstarzinger@chromium.org
      also-by=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424955
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59099}
      258371bd
  4. 19 Dec, 2018 2 commits
  5. 17 Dec, 2018 2 commits
  6. 19 Nov, 2018 1 commit
  7. 18 Oct, 2018 1 commit
  8. 10 Oct, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Use a tuple as the instance for JS imports · a2b34806
      Ben L. Titzer authored
      This CL refactors the implementation of WASM->JS import wrappers in order
      to make the wrapper code shareable. Instead of specializing to the import
      index, we use a tuple as the object ref in the both the import and indirect
      tables. The tuple allows the wrapper code to load both the calling
      instance and the target callable, rather than relying on code specialization.
      
      This requires some tricky codegen machinery, because WASM call descriptors
      expect an instance argument in a given register, yet the wrappers receive
      a tuple, the code generator must generate a prologue that loads the
      instance (and the callable), since it is not possible to express this at
      the graph level.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
      Reviewed-on: https://chromium-review.googlesource.com/c/1268237
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56520}
      a2b34806
  9. 22 Jun, 2018 1 commit
  10. 21 Jun, 2018 1 commit
  11. 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
  12. 14 Jun, 2018 2 commits
  13. 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
  14. 03 May, 2018 1 commit
  15. 17 Apr, 2018 1 commit
  16. 16 Apr, 2018 1 commit
  17. 04 Apr, 2018 1 commit
  18. 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
  19. 16 Jan, 2018 1 commit
  20. 12 Jan, 2018 1 commit
  21. 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
  22. 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
  24. 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
  25. 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
  26. 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
  27. 29 Nov, 2017 1 commit
  28. 21 Nov, 2017 1 commit
  29. 25 Sep, 2017 1 commit
  30. 22 Sep, 2017 1 commit
  31. 04 Sep, 2017 1 commit
  32. 24 Aug, 2017 1 commit
  33. 01 Aug, 2017 1 commit
  34. 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
  35. 03 Nov, 2016 1 commit