1. 02 Feb, 2021 2 commits
    • Milad Fa's avatar
      PPC/s390: Fix frame size to account for q registers · f8360140
      Milad Fa authored
      Port 45b99aaa
      
      Original Commit Message:
      
          In https://crrev.com/c/2645694 we push the full q registers before lazy
          compile, but we did not change the fixed frame size to account for the
          wider registers being pushed.
      
          This manifested in the frame having data like:
      
          (gdb) x/10xg start.ptr_
          0x7f5576ff3eb0: 0x0000000000000000      0x0000336b08202759
          0x7f5576ff3ec0: 0x7ff000007f801000      0x0000000000000000
          0x7f5576ff3ed0: 0x7ff000007f801001      0x0000000000000000
          0x7f5576ff3ee0: 0x7ff000007f801002      0x0000000000000000
          0x7f5576ff3ef0: 0x7ff000007f801003      0x0000000000000000
      
          The GC then walks part of this frame, thinking that 0x7ff000007f801003
          is a heap object, and then crashes.
      
          Add some static_asserts (similar to builtins-x64) to remind ourselves
          that the pushed registers have to match the size in frame constants.
      
      R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: I994f1b7fecbb24ea97d846b1eed98201bc3b08ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2669308Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#72496}
      f8360140
    • 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
  2. 01 Feb, 2021 2 commits
  3. 28 Jan, 2021 1 commit
  4. 22 Jan, 2021 1 commit
  5. 19 Jan, 2021 1 commit
  6. 18 Jan, 2021 1 commit
  7. 16 Dec, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: Reland "[Turboprop] Move dynamic check maps immediate args to deopt exit." · 07f0b7a4
      Milad Fa authored
      Port 7bdb0fbb
      
      Original Commit Message:
      
          This is a reland of b2a611d8
      
          Original change's description:
          > [Turboprop] Move dynamic check maps immediate args to deopt exit.
          >
          > Rather than loading the immediate arguments required by the
          > dynamic check maps builtin into registers in the fast-path,
          > instead insert them into the instruction stream in the deopt
          > exit and have the builtin load them into registers itself.
          >
          > BUG=v8:10582
          >
          > Change-Id: I66716570b408501374eed8f5e6432df64c6deb7c
          > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589736
          > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
          > Reviewed-by: Sathya Gunasekaran  <gsathya@chromium.org>
          > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#71790}
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: I83fc0f3e3ebcf19ca4303e50aae94d7b353cd0ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595708Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#71809}
      07f0b7a4
  8. 02 Dec, 2020 2 commits
    • Milad Fa's avatar
      PPC/s390: [cleanup][TurboProp] Unify DynamicMapChecks names. · 073d0690
      Milad Fa authored
      Port 7730fd94
      
      Original Commit Message:
      
          Unifies various operators for dynamic map checks with the naming
          scheme of DynamicCheckMaps (to be similar to CheckMaps.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=v8:10582
      LOG=N
      
      Change-Id: I0c7665eb5ec3cd0b0b8217af3ec8e9e18a3d3055
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569593Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#71574}
      073d0690
    • 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
  9. 12 Nov, 2020 1 commit
  10. 11 Nov, 2020 1 commit
  11. 10 Nov, 2020 2 commits
  12. 02 Nov, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: [turboprop] Fix IET to check optimization marker before optimized code · f4d5e8a3
      Milad Fa authored
      Port 808a5d76
      
      Original Commit Message:
      
          InterpreterEntryTrampoline checks
          1. If there is any optimization marker, and process the marker by
          calling the correct runtime function
          2. If there is any optimized code, it installs optimized code and starts
          executing optimized code.
      
          Earlier it was OK to do these two checks in any order, since it wasn't
          possible that we have both a marker and optimized code. Turboprop code
          calls out to IET to process the optimization marker / install next tier
          optimized code. So we have to check for optimization marker before we
          check for optimized code.
      
      R=mythria@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: I37f470809e244f675862e109ae609170a2b019f0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2513792Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#70925}
      f4d5e8a3
  13. 30 Oct, 2020 1 commit
  14. 29 Oct, 2020 1 commit
  15. 28 Oct, 2020 1 commit
    • Milad Fa's avatar
      PPC/s390: [turboprop] Add a slot for optimization marker in feedback vector · 014112a8
      Milad Fa authored
      Port d7ece57e
      
      Original Commit Message:
      
          Optimization marker and the optimized code used to share the same slot
          in the feedback vector as they were mutually exclusive. With turboprop
          we would want to mark the function for tier up to Turbofan while holding
          the optimized code for Turboprop. So this cl uses the existing padding
          field to hold the optimization marker instead.
      
          As a driveby, removes unused JSFunction::ClearOptimizedCodeSlot function
          and fixes a minor bug in Runtime_GetOptimizationStatus.
      
      R=mythria@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
      BUG=
      LOG=N
      
      Change-Id: Ie635fd05c26f70124076b9c51c0c70a2b948af69
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2505621Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
      Commit-Queue: Milad Fa <mfarazma@redhat.com>
      Cr-Commit-Position: refs/heads/master@{#70854}
      014112a8
  16. 22 Oct, 2020 1 commit
  17. 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
  18. 14 Oct, 2020 1 commit
  19. 03 Sep, 2020 1 commit
  20. 01 Sep, 2020 1 commit
  21. 28 Jul, 2020 1 commit
  22. 06 May, 2020 1 commit
  23. 28 Apr, 2020 1 commit
  24. 20 Mar, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [interpreter] Make IterationBody StackChecks implicit within JumpLoop · e70331f9
      Milad Farazmand authored
      Port a447a44f
      
      Original Commit Message:
      
          Since now the IterationBody StackChecks are implicit within JumpLoops,
          we are able to eagerly deopt in them. If we do that, whenever we advance
          to the next bytecode we don't have to advance to the next literal
          bytecode, but instead "advance" in the sense of doing the JumpLoop.
      
          Adding tests that test this advancing for wide and extra wide JumpLoops.
      
          Also, marking JumpLoop as needing source positions since now it has
          the ability of causing an interrupt.
      
      R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I5bec2212d040801d67426a8639d20fe96035d813
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111832Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66814}
      e70331f9
  25. 16 Mar, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [wasm] Fix registers spilled in DebugBreak frame · e54259ee
      Milad Farazmand authored
      Port e47f9a9d
      
      Original Commit Message:
      
          The set of registers to spill was wrong. Instead of spilling wasm
          parameter registers (like the WasmCompileLazy builtin), we should spill
          all registers that are being used as Liftoff cache registers.
          This CL defines platform-specific WasmDebugBreakFrameConstants which
          hold the set of registers to spill. This set is used in the builtin, and
          will later be used for inspecting the spilled registers.
      
          In order to iterate bit sets more easily in both direction (MSB to LSB
          or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
          which provides the respective iterators.
      
      R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ic308a7712f080e43a0c45f496b087ce8450f657a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105563Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66736}
      e54259ee
  26. 02 Mar, 2020 1 commit
  27. 25 Feb, 2020 1 commit
  28. 21 Feb, 2020 1 commit
  29. 10 Feb, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [interpreter] Make FunctionEntry StackCheck bytecodes implicit · 9987977e
      Milad Farazmand authored
      Port 9d3dc6f2
      
      Original Commit Message:
      
        FunctionEntry StackChecks is one of the two cases where we generate a
        StackCheck bytecode. In these cases, we do stack check against the js
        limit (not to be confused with the real js limit). Their purpose is to
        be able to interrupt the running code.
      
        We can omit the FunctionEntry StackCheck by embedding its code into
        the InterpreterEntryTrampoline builtin. We save one bytecode per
        interpreted function.
      
        This change has rippling effects for optimized code, as well as the
        deoptimizer.
      
      R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: If797a8acba7581c9c388ac09b5554c774c5993a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2048124Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66210}
      9987977e
  30. 05 Feb, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [wasm] Add builtin and runtime function for debug breaks · d1edf08d
      Milad Farazmand authored
      Port 59bda196
      
      Original Commit Message:
      
          This CL adds the "WasmDebugBreak" builtin for x64, ia32, arm and arm64.
          It stores all wasm parameter registers to the stack and calls the
          respective runtime function.
          The runtime function does not do anything yet, but the
          inspector/debugger/wasm-set-breakpoint-liftoff test will already execute
          both the builtin and the runtime function.
      
      R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I881a22f1e7c8f9c0714caaa0de75e00177da51e4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2038136Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#66138}
      d1edf08d
  31. 16 Jan, 2020 1 commit
  32. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  33. 05 Dec, 2019 1 commit
  34. 19 Nov, 2019 1 commit
  35. 18 Nov, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: Add a debug v8 API SetDetachedWindowReason · db18e495
      Milad Farazmand authored
      Port 63dc5556
      
      Original Commit Message:
      
          A window is a Blink concept. This API marks the context as backing
          a detached window. This doesn't necessarily mean that the context is
          detached.
      
          Every time a JS function is called within a context that has a non-zero
          DetachedWindowReason, Runtime::kReportDetachedWindowAccess is invoked,
          which will report this call to Blink via a callback, which in turn can
          report number of such calls via UKM metrics.
      
      R=bartekn@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2243898115287e103ba5700499b9547fe155dceb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1919954Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#65018}
      db18e495
  36. 14 Nov, 2019 1 commit