1. 17 Feb, 2021 1 commit
  2. 02 Feb, 2021 1 commit
    • Milad Fa's avatar
      PPC: Push the full q register before lazy compile · d913f046
      Milad Fa authored
      V8 uses the same set of fp param registers as Simd param registers.
      As these registers are two different sets on ppc we must make
      sure to also save them when Simd is enabled.
      Check the comments under crrev.com/c/2645694 for more details.
      
      Port 3b302d5c
      
      Original Commit Message:
      
          If a lazy compilation happens in between 2 Wasm calls, we need to save
          the full Q register, since we can have live v128 values.
      
      R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: Icdd0a6d38225a866b61651ff406598c144c25ebf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667952Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#72492}
      d913f046
  3. 19 Jan, 2021 1 commit
  4. 16 Dec, 2020 1 commit
  5. 15 Dec, 2020 1 commit
  6. 02 Dec, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: [Turboprop] Move deoptimizations for dynamic map checks into builtin. · 2bc979aa
      Milad Fa authored
      Port b6643320
      
      Original Commit Message:
      
          In order to reduce the codegen size of dynamic map checks, add the
          ability to have an eager with resume deopt point, which can call
          a given builitin to perform a more detailed check than can be done
          in codegen, and then either deoptimizes itself (as if the calling
          code had performed an eager deopt) or resumes execution in the
          calling code after the check.
      
          In addition, support for adding extra arguments to a
          deoptimization continuation is added to enable us to pass the
          necessary arguments to the DynamicMapChecks builtin.
      
          Finally, a trampoline is added to the DynamicMapChecks which saves
          the registers that might be clobbered by that builtin, to avoid
          having to save them in the generated code. This trampoline also
          performs the deoptimization based on the result of the
          DynamicMapChecks builtin.
      
          In order to ensure both the trampoline and DynamicMapChecks
          builtin have the same call interface, and to limit the number
          of registers that need saving in the trampoline, the
          DynamicMapChecks builtin is moved to be a CSA builtin with a
          custom CallInterfaceDescriptor, that calls an exported Torque
          macro that implements the actual functionality.
      
          All told, this changes the codegen for a monomorphic dynamic
          map check from:
              movl rbx,<expected_map>
              cmpl [<object>-0x1],rbx
              jnz <deferred_call>
             resume_point:
              ...
             deferred_call:
              <spill registers>
              movl rax,<slot>
              movq rbx,<object>
              movq rcx,<handler>
              movq r10,<DynamicMapChecks>
              call r10
              cmpq rax,0x0
              jz <restore_regs>
              cmpq rax,0x1
              jz <deopt_point_1>
              cmpq rax,0x2
              jz <deopt_point_2>
              int3l
             restore_regs:
              <restore_regs>
              jmp <resume_point>
              ...
             deopt_point_1:
              call Deoptimization_Eager
             deopt_point_2:
              call Deoptimization_Bailout
      
              movl rcx,<expected_map>
              movq rdx,<handler>
              cmpl [<object>-0x1],rcx
              jnz <deopt_point>
             resume_point:
              ...
             deopt_point:
              call DynamicMapChecksTrampoline
              jmp <resume_point>
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=v8:10582
      LOG=N
      
      Change-Id: I0739c1b40ed06bb22b73ebe1833ea648b540882a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569359Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#71571}
      2bc979aa
  7. 12 Nov, 2020 1 commit
  8. 20 Oct, 2020 1 commit
    • Junliang Yan's avatar
      PPC/s390: [deoptimizer] Change deopt entries into builtins · 5d5ed19f
      Junliang Yan authored
      Port 7f58ced7
      
      Original Commit Message:
      
          While the overall goal of this commit is to change deoptimization
          entries into builtins, there are multiple related things happening:
      
          - Deoptimization entries, formerly stubs (i.e. Code objects generated
            at runtime, guaranteed to be immovable), have been converted into
            builtins. The major restriction is that we now need to preserve the
            kRootRegister, which was formerly used on most architectures to pass
            the deoptimization id. The solution differs based on platform.
          - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
          - Removed heap/ support for immovable Code generation.
          - Removed the DeserializerData class (no longer needed).
          - arm64: to preserve 4-byte deopt exits, introduced a new optimization
            in which the final jump to the deoptimization entry is generated
            once per Code object, and deopt exits can continue to emit a
            near-call.
          - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
            sizes by 4/8, 5, and 5 bytes, respectively.
      
          On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
          by using the same strategy as on arm64 (recalc deopt id from return
          address). Before:
      
           e300a002       movw r10, <id>
           e59fc024       ldr ip, [pc, <entry offset>]
           e12fff3c       blx ip
      
          After:
      
           e59acb35       ldr ip, [r10, <entry offset>]
           e12fff3c       blx ip
      
          On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
          with CFI). Additionally, up to 4 builtin jumps are emitted per Code
          object (max 32 bytes added overhead per Code object). Before:
      
           9401cdae       bl <entry offset>
      
          After:
      
           # eager deoptimization entry jump.
           f95b1f50       ldr x16, [x26, <eager entry offset>]
           d61f0200       br x16
           # lazy deoptimization entry jump.
           f95b2b50       ldr x16, [x26, <lazy entry offset>]
           d61f0200       br x16
           # the deopt exit.
           97fffffc       bl <eager deoptimization entry jump offset>
      
          On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      
           bb00000000     mov ebx,<id>
           e825f5372b     call <entry>
      
          After:
      
           e8ea2256ba     call <entry>
      
          On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      
           49c7c511000000 REX.W movq r13,<id>
           e8ea2f0700     call <entry>
      
          After:
      
           41ff9560360000 call [r13+<entry offset>]
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I49e4c92759043e46beb3c76c97823285b16feeef
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2486225Reviewed-by: 's avatarMilad Fa <mfarazma@redhat.com>
      Commit-Queue: Junliang Yan <junyan@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#70637}
      5d5ed19f
  9. 14 Oct, 2020 1 commit
  10. 01 Sep, 2020 1 commit
  11. 04 Aug, 2020 1 commit
  12. 06 May, 2020 1 commit
  13. 28 Apr, 2020 1 commit
  14. 17 Mar, 2020 1 commit
  15. 25 Feb, 2020 1 commit
  16. 10 Feb, 2020 2 commits
  17. 08 Nov, 2019 1 commit
  18. 04 Nov, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 29112b47
      Milad Farazmand authored
      Port 352bbb12
      
      Original Commit Message:
      
          This is a reland of 855591a5
      
          Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
          Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
      
          Original change's description:
          > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
          >
          > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
          >
          > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
          >
          > Creates an allow-list of builtins that can still go in code_space
          > including all TFJ builtins and a small manual list that should be pared
          > down in the future.
          >
          > For builtins that go in RO_SPACE a Code object is created that contains an
          > immediate trap instruction. Generally these Code objects are still no
          > smaller than CODE_SPACE Code objects because of the Code object alignment
          > requirements. This will hopefully be addressed in a follow-up CL either by
          > relaxing them or removing the instruction stream completely.
          >
          > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
          > increases by the same amount.
          >
          > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
          > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
          > Commit-Queue: Dan Elphick <delphick@chromium.org>
          > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
          > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#64700}
      
      R=delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: If150434119828a87e295b0639c934392812bb345
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1896904Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64741}
      29112b47
  19. 31 Oct, 2019 4 commits
    • Milad Farazmand's avatar
      Revert "PPC/s390: Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 32b2d32c
      Milad Farazmand authored
      This reverts commit 94456e5c.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > PPC/s390: Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      > 
      > Port 855591a5
      > 
      > Original Commit Message:
      > 
      >     Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
      > 
      >     [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      > 
      >     Creates an allow-list of builtins that can still go in code_space
      >     including all TFJ builtins and a small manual list that should be pared
      >     down in the future.
      > 
      >     For builtins that go in RO_SPACE a Code object is created that contains an
      >     immediate trap instruction. Generally these Code objects are still no
      >     smaller than CODE_SPACE Code objects because of the Code object alignment
      >     requirements. This will hopefully be addressed in a follow-up CL either by
      >     relaxing them or removing the instruction stream completely.
      > 
      >     In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
      >     increases by the same amount.
      > 
      > R=​delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      > BUG=
      > LOG=N
      > 
      > Change-Id: Ibd0713a17df9c873692553f2d57f4ba36bcdb342
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893746
      > Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
      > Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      > Cr-Commit-Position: refs/heads/master@{#64704}
      
      TBR=michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com,delphick@chromium.org,miladfar@ca.ibm.com
      
      Change-Id: I808a4220892dcfef66b4b9d90ab43bf403d2e9b0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1894353Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64705}
      32b2d32c
    • Milad Farazmand's avatar
      PPC/s390: Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE · 94456e5c
      Milad Farazmand authored
      Port 855591a5
      
      Original Commit Message:
      
          Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
      
          [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      
          Creates an allow-list of builtins that can still go in code_space
          including all TFJ builtins and a small manual list that should be pared
          down in the future.
      
          For builtins that go in RO_SPACE a Code object is created that contains an
          immediate trap instruction. Generally these Code objects are still no
          smaller than CODE_SPACE Code objects because of the Code object alignment
          requirements. This will hopefully be addressed in a follow-up CL either by
          relaxing them or removing the instruction stream completely.
      
          In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
          increases by the same amount.
      
      R=delphick@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ibd0713a17df9c873692553f2d57f4ba36bcdb342
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893746Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64704}
      94456e5c
    • Milad Farazmand's avatar
      PPC/s390: [codegen] Removed ParameterCount class · 9d77a8af
      Milad Farazmand authored
      Port 1e696896
      
      Original Commit Message:
      
          It was used only with Register inputs, so we can replace its uses with
          the Registers themselves.
      
      R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I6b325ccefd226c96de45a74068b1d02611a846cb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1892195Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64677}
      9d77a8af
    • Milad Farazmand's avatar
      PPC/s390: [builtins] Remove ParameterCount uses from InvokeFunction(Code) · dba86292
      Milad Farazmand authored
      Port 46648402
      
      Original Commit Message:
      
          CallDebugOnFunctionCall was always using Registers and not Immediates.
          Then ParameterCount is not really needed. Since updating that, we
          could update other functions, e.g InvokeFunction, to only use
          registers too.
      
          Also removed now irrelevant variables, e.g definitely_mismatches.
      
      R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie0348998503bf4f416440f056e4296d22d064d4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1892171Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64665}
      dba86292
  20. 30 Oct, 2019 2 commits
  21. 23 Oct, 2019 1 commit
  22. 17 Oct, 2019 2 commits
    • Milad Farazmand's avatar
      PPC/s390: Reland^2 "[runtime] Move Context::native_context to the map" · 36ab93d8
      Milad Farazmand authored
      Port 3cad6bf5
      
      Original Commit Message:
      
          This is a reland of c7c47c68.
      
          This makes TSAN happy in addition to:
      
          Previously I presumed that the context read from a frame in the profiler was
          a valid context. Turns out that on non-intel we're not guaranteed that the
          frame is properly set up. In the case we looked at, the profiler took a
          sample right before writing the frame marker indicating a builtin frame,
          causing the "context" pointer from that frame to be a bytecode array. Since
          we'll read random garbage on the stack as a possible context pointer, I made
          the code reading the native context from it a little more defensive.
      
          Original change's description:
          > [runtime] Move Context::native_context to the map
          >
          > Remove the native context slot from contexts by making context maps
          > native-context-specific. Now we require 2 loads to go from a context to the
          > native context, but we have 1 field fewer to store when creating contexts.
          >
          > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
          > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
          > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
          > Reviewed-by: Igor Sheludko <ishell@chromium.org>
          > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
          > Reviewed-by: Maya Lekova <mslekova@chromium.org>
          > Reviewed-by: Georg Neis <neis@chromium.org>
          > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
          > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#64296}
      
      R=verwaest@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I48b21f189e782a338eb2508edd57b7b2cf5ce240
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865607Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64362}
      36ab93d8
    • Milad Farazmand's avatar
      PPC: allow for calling CFunctions without function descriptors on AIX. · 07ee86a5
      Milad Farazmand authored
      The calling conventions on AIX uses function descriptors,
      which means that pointers to functions do not point to code,
      but instead point to metadata about them. When calling JITed code,
      we must assure to use function descriptors instead of raw pointers when
      needed. Before this CL 213504b9, all CallCFunction on AIX were guaranteed to have
      function descriptors. Starting form the CL mentioned above, CallCFunction can also
      Jump to a Trampoline which does not have a function descriptor, hence a new
      "CallCFunctionWithoutFunctionDescriptor" method is proposed to deal with this issue.
      
      BUG= v8:9766
      
      Change-Id: I9343c31c812f5d4dda8503a5adf024b24dbde072
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825961
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64357}
      07ee86a5
  23. 24 Sep, 2019 1 commit
  24. 29 Aug, 2019 1 commit
  25. 14 Jun, 2019 1 commit
  26. 13 Jun, 2019 1 commit
  27. 28 May, 2019 1 commit
  28. 27 May, 2019 1 commit
  29. 24 May, 2019 1 commit
  30. 23 May, 2019 1 commit
  31. 21 May, 2019 1 commit
  32. 15 May, 2019 1 commit
  33. 01 Apr, 2019 1 commit
  34. 26 Mar, 2019 1 commit