1. 27 May, 2019 3 commits
  2. 24 May, 2019 1 commit
  3. 23 May, 2019 4 commits
  4. 22 May, 2019 1 commit
  5. 21 May, 2019 1 commit
  6. 20 May, 2019 4 commits
  7. 17 May, 2019 3 commits
  8. 16 May, 2019 3 commits
  9. 14 May, 2019 1 commit
  10. 10 May, 2019 1 commit
  11. 08 May, 2019 2 commits
  12. 30 Apr, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: Reland "[ptr-compr] New RelocInfo for compressed pointers." · 18c29ab9
      Milad Farazmand authored
      Port ed319e84
      
      Original Commit Message:
      
          Failure addressed by not exposing the new test to the jitless environment.
          (jgruber@ on TBR).
      
          New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
          compressed pointers in generated code. Enum name EMBEDDED_OBJECT
          changed to FULL_EMBEDDED_OBJECT.
      
          RelocInfo::[set_]target_object() abstract away the difference between
          FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      
          Compressed embedded objects can only be created at this time on
          x64 with pointer compression turned on. Arm64 constant pools don't
          support compressed objects at this time.
      
      R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I8bdb5391fd2b2565d2fcaf6c806fcdbe1a1f27b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1589862Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#61123}
      18c29ab9
  13. 29 Apr, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [cleanup] Use Vector::begin instead of Vector::start · 08756826
      Milad Farazmand authored
      Port 4b0f9c85
      
      Original Commit Message:
      
          Our {Vector} template provides both {start} and {begin} methods. They
          return exactly the same value. Since the {begin} method is needed for
          iteration, and is also what standard containers provide, this CL
          switches all uses of the {start} method to use {begin} instead.
      
          Patchset 1 was auto-generated by using this clang AST matcher:
              callExpr(
                  callee(
                    cxxMethodDecl(
                      hasName("start"),
                      ofClass(hasName("v8::internal::Vector")))
                  ),
                  argumentCountIs(0))
      
          Patchset 2 was created by running clang-format. Patchset 3 then
          removes the now unused {Vector::start} method.
      
      R=clemensh@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I119532691af31a3db1107c47de8b6f0c84697b5c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588226Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#61102}
      08756826
  14. 23 Apr, 2019 1 commit
  15. 11 Apr, 2019 1 commit
  16. 08 Apr, 2019 1 commit
  17. 01 Apr, 2019 1 commit
  18. 26 Mar, 2019 1 commit
  19. 25 Mar, 2019 1 commit
  20. 19 Mar, 2019 1 commit
  21. 15 Mar, 2019 1 commit
  22. 12 Mar, 2019 1 commit
  23. 08 Mar, 2019 1 commit
  24. 07 Mar, 2019 1 commit
  25. 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
  26. 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
  27. 15 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [builtins] Improve CallApiCallback calling convention. · 81bb8aed
      Junliang Yan authored
      Port c142e0a2
      
      Original Commit Message:
      
          Refactor the CallApiCallback builtin to
      
          - pass the context as with other stubs, and
          - pass holder and call data in registers.
      
          This avoids having to place holder and call data onto the stack, and
          thus makes it possible to easily call the CallApiCallback builtin from
          other builtins while just forwarding the (stack) arguments. The idea
          is to use this in the future to optimize the general case of calling
          into any API method via a FunctionTemplateInfo and doing appropriate
          security and/or interface checks upfront as necessary (eventually making
          the HandleApiCall C++ builtin obsolete at some point).
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I94583d1e0fa7c4696e628c363fefe273c8c5cab9
      Reviewed-on: https://chromium-review.googlesource.com/c/1475331Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#59633}
      81bb8aed