1. 31 Mar, 2020 1 commit
  2. 17 Mar, 2020 1 commit
  3. 27 Feb, 2020 1 commit
  4. 25 Feb, 2020 1 commit
  5. 10 Feb, 2020 1 commit
  6. 08 Nov, 2019 1 commit
  7. 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
  8. 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
  9. 30 Oct, 2019 2 commits
  10. 17 Oct, 2019 1 commit
    • 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
  11. 30 Sep, 2019 1 commit
  12. 24 Sep, 2019 1 commit
  13. 29 Aug, 2019 1 commit
  14. 14 Jun, 2019 1 commit
  15. 13 Jun, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 27 May, 2019 1 commit
  18. 24 May, 2019 1 commit
  19. 23 May, 2019 1 commit
  20. 21 May, 2019 1 commit
  21. 23 Apr, 2019 1 commit
  22. 01 Apr, 2019 1 commit
  23. 26 Mar, 2019 1 commit
  24. 25 Mar, 2019 1 commit
  25. 08 Mar, 2019 1 commit
  26. 25 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [objects] Free one bit in the SharedFunctionInfo::flags. · 942dc585
      Junliang Yan authored
      Port 591408cb
      
      Original Commit Message:
      
          We'll need one bit in the SharedFunctionInfo::flags to record whether
          it's safe to skip arguments adaptor frames (for v8:8895), so this
          just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
          redundant, since the same information is already available in the
          SharedFunctionInfo::FunctionKindBits, and most places in the code
          use that already, with the exception of the JSConstructStubGeneric
          builtin.
      
          This changes the JSConstructStubGeneric builtin to just check the
          function kind instead of testing the explicit bit, which also makes
          this more consistent. It seems like there's not much overhead to
          that, doing an additional bitmasking plus two comparisons instead
          of one. This shouldn't really matter since invocation and execution
          of the constructors is going to dominate and optimized code inlines
          all of this anyways. If this turns out to affect performance, we
          can still look into encoding the FunctionKindBits more cleverly.
      
          the shift when accessing the function kind. This seems logic, since
          for the actual boolean bit fields it doesn't matter where they are
          in the flags, whereas for the function kind this saves one shift.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I4e3ba5a066285bf50e869c32228d79d26d57258f
      Reviewed-on: https://chromium-review.googlesource.com/c/1486411Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#59837}
      942dc585
  27. 21 Feb, 2019 1 commit
    • Farazmand's avatar
      PPC/s390: [cleanup] Remove obsolete representations. · f8696d4e
      Farazmand authored
      Port adb7e37b
      
      Original Commit Message:
      
          In the Crankshaft days we (mis)used the Representation to also express
          the various internal representations that the compiler understands. But
          with TurboFan we now have proper MachineRepresentation and MachineType,
          which do that independently. So there's no need to have this in the
          Representation class anymore, and instead the Representation class only
          needs to deal with the field representations.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie3c8062786d5fd42872e22be01cea45d719ea0a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1479972Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#59767}
      f8696d4e
  28. 11 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler · 47270ebf
      Junliang Yan authored
      Port 9e060e47
      
      Original Commit Message:
      
          When BUILDING_V8_SHARED in release builds __declspec(dllexport)
          causes generation of implicit constructors in the forwarding class
          while its deleted in TurboAssemblerBase, which leads to compilation
          errors like:
      
          In file included from gen/v8/v8_base_jumbo_6.cc:41:
          In file included from .\../../v8/src/interface-descriptors.cc:7:
          In file included from ../../v8\src/macro-assembler.h:40:
          ../../v8\src/x64/macro-assembler-x64.h(92,9):  error: call to deleted constructor of 'v8::internal::TurboAssemblerBase'
                : TurboAssemblerBase(std::forward<Args>(args)...) {}
                  ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
          ../../v8\src/x64/macro-assembler-x64.h(536,25):  note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here
          class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler {
                                  ^
          ../../v8\src/turbo-assembler.h(127,34):  note: 'TurboAssemblerBase' has been explicitly marked deleted here
            DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase);
                                           ^
          1 error generated.
      
          The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913
      
      R=hop2deep@gmail.com, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2a6e555b028583b89402b257e40757f34f3301c1
      Reviewed-on: https://chromium-review.googlesource.com/c/1463179Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#59499}
      47270ebf
  29. 28 Jan, 2019 1 commit
  30. 17 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: Use forwarding constructors for MacroAssembler · 30617b77
      Junliang Yan authored
      Port edab9a20
      
      Original Commit Message:
      
          and TurboAssembler. Instead of listing all the different combinations
          of arguments (which is one more now, temporarily), just forward all
          arguments down via MacroAssembler and TurboAssembler to
          TurboAssemblerBase.
          Interestingly, this requires more specific types sometimes (int instead
          of size_t), since further down the forwarding chain, the compiler does
          not recognize any more that the value is a constant, and emits a
          warning about a possibly truncating implicit conversion.
      
      R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I6dddc58b81d020570087393158f4ad0f37efa9ce
      Reviewed-on: https://chromium-review.googlesource.com/c/1417379Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58889}
      30617b77
  31. 11 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [Deopt] Remove jump table in prologue of deopt entries. · 2afe66c5
      Junliang Yan authored
      Port 4ab96a9a
      
      Original Commit Message:
      
          Remove the use of a jump table in the prologue of the deopt entries
          and instead pass the bailout id explicitly in a register when calling
          the deopt entry routine from optimized code. This unifies the logic
          with the way the Arm64 code works. It saves the following amount of
          memory in code stubs:
      
           - arm:  384KB
           - ia32: 480KB
           - x64:  240KB
      
          This could be offset by a slight increase in the size of optimized code
          for loading the immediate, however this impact should be minimal and
          will scale with the maximum number of bailout ids (e.g., the size of
          code will increase by one instruction per bailout id on Arm, therefore
          ~98,000 bailouts will be needed before the overhead is greater than
          the current fixed table size).
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Id5762334b21e6a91e5ce44b7db1e38ace9147372
      Reviewed-on: https://chromium-review.googlesource.com/c/1406026
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58752}
      2afe66c5
  32. 07 Jan, 2019 1 commit
  33. 03 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [nojit] Add a kCallBuiltinPointer call kind · 4812f2af
      Junliang Yan authored
      Port f323a5f4
      
      Original Commit Message:
      
          Currently, Torque's builtin pointers store a Code target underneath and
          callsites generate a kArchCallCodeObject opcode. When embedded builtins
          are enabled, the call thus first calls the on-heap trampoline, which
          finally jumps to the target off-heap builtin code.
      
          This will no longer be possible in jitless mode, since on-heap code must
          not be executable.
      
          As a step towards changing the way builtin pointers are called
          (function pointers will hold the builtin index as a Smi, and callsites
          look up the off-heap target address and jump there), this CL adds a
          dedicated opcode for builtin pointer calls to the compiler pipeline.
      
          The calling mechanism itself is unchanged, changes there will happen
          in a follow-up.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2d2229227e1c62e7c2515d4f5cb3d4dae49b3dd4
      Reviewed-on: https://chromium-review.googlesource.com/c/1393913Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58525}
      4812f2af
  34. 02 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: Reland "[nojit] Remove code stubs" · 4af9ec6a
      Junliang Yan authored
      Port 24e76616
      
      Original Commit Message:
      
          This is a reland of f849396c
      
          Original change's description:
          > [nojit] Remove code stubs
          >
          > All stubs have been migrated to builtins. This CL removes most related
          > code.
          >
          > Bug: v8:7777, v8:5784
          > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
          > Reviewed-on: https://chromium-review.googlesource.com/c/1365284
          > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
          > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
          > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
          > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
          > Reviewed-by: Yang Guo <yangguo@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#58093}
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie05463245c24975804a8bb7ffdf902c70e042127
      Reviewed-on: https://chromium-review.googlesource.com/c/1393302Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58504}
      4af9ec6a
  35. 19 Dec, 2018 1 commit
  36. 07 Dec, 2018 1 commit