1. 21 May, 2019 1 commit
  2. 20 May, 2019 4 commits
  3. 17 May, 2019 2 commits
  4. 16 May, 2019 1 commit
  5. 15 May, 2019 1 commit
  6. 10 May, 2019 1 commit
  7. 08 May, 2019 1 commit
    • Pierre Langlois's avatar
      [ic] Do not decode instructions to detect deoptimized code. · 0d8ec36b
      Pierre Langlois authored
      This fixes a crash when using --trace-ic on Arm64 debug. For a given return
      address, the assembler's `target_address_from_return_address()` method will
      displace it to give you the call-site address. However, this is fragile because
      it needs to decode the instruction stream to distinguish between different call
      sequences. So it triggered an assertion on Arm64 because we now use BL for
      builtin to buitin calls.
      
      We only use this when tracing IC states to detect if the caller is a deoptimized
      function. But to do this it doesn't matter if the address we have is the return
      or the call-site address. So we can just remove the need for the fragile
      Assembler method.
      
      As a drive-by, also remove `return_address_from_call_start()` which was doing
      the opposite and was unused.
      
      Change-Id: I5988d17eadd1652ed85d662e62bc4c579665dd31
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594566
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61337}
      0d8ec36b
  8. 03 May, 2019 1 commit
  9. 02 May, 2019 1 commit
  10. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored
      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.
      
      NOPRESUBMIT=true
      
      Bug: v8:7703
      TBR: jgruber@chromium.org
      Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  11. 29 Apr, 2019 3 commits
    • Ross McIlroy's avatar
      Revert "[ptr-compr] New RelocInfo for compressed pointers." · 7e677b2e
      Ross McIlroy authored
      This reverts commit b5da9fcb.
      
      Reason for revert: Breaks pointer compression bot:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3098
      
      Original change's description:
      > [ptr-compr] New RelocInfo for compressed pointers.
      > 
      > 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.
      > 
      > Bug: v8:7703
      > Change-Id: I03bfd84effa33c65cf9bcefa5df680ab7eace9dd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547661
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61076}
      
      TBR=ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org
      
      Change-Id: I262b2b98315fa987c5a66b1050dc726563ccdb2d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588135Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61087}
      7e677b2e
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      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=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
    • Mike Stanton's avatar
      [ptr-compr] New RelocInfo for compressed pointers. · b5da9fcb
      Mike Stanton authored
      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.
      
      Bug: v8:7703
      Change-Id: I03bfd84effa33c65cf9bcefa5df680ab7eace9dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547661
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61076}
      b5da9fcb
  12. 26 Apr, 2019 1 commit
  13. 24 Apr, 2019 1 commit
  14. 18 Apr, 2019 1 commit
  15. 11 Apr, 2019 2 commits
    • Clemens Hammacher's avatar
      [wasm][x64] Use near jump in jump table · 3cd6705f
      Clemens Hammacher authored
      On x64, we allocate one big code region such that we can use near jumps
      and near calls. The jump table did not make use of that design yet.
      This CL changes that by emitting jump table slots as near jumps. This
      also speeds up patching jump table slots significantly, since far jumps
      populate the inline constant pool, which is unneeded overhead in this
      case.
      As a drive-by, this CL cleans up the API of near_call and near_jmp. The
      current semantics is broken, and only works because this is only used
      for WebAssembly calls which are patched anyway after code generation.
      Also, x64 now uses the same path in test-jump-table-assembler.cc as
      arm64 to ensure that all targets are within near-call-distance.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8916
      Change-Id: Iffc34e248b72167307ffdab62dd2212c4ae86a32
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561313Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60777}
      3cd6705f
    • Clemens Hammacher's avatar
      [assembler] Remove unconditional code target reservation · 4a7563d3
      Clemens Hammacher authored
      Some code - especially WebAssembly - does not make use of the code
      target vector. Unconditionally reserving 100 entries adds unnecessary
      overhead e.g. to jump table patching (~10%). This CL just removes this
      reservation.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8916
      Change-Id: I671820f3eb413fa2d03cef4bbf06adfc7a585266
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1559868Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60772}
      4a7563d3
  16. 08 Apr, 2019 1 commit
  17. 03 Apr, 2019 1 commit
    • Paolo Severini's avatar
      Reland "V8 x64 backend doesn't emit ABI compliant stack frames" · 969cb0c7
      Paolo Severini authored
      This is a reland of 3cda21de
      
      Original change's description:
      > V8 x64 backend doesn't emit ABI compliant stack frames
      > 
      > On 64 bit Windows, the OS stack walking does not work because the V8 x64
      > backend doesn't emit unwinding info and also because it doesn't emit ABI
      > compliant stack frames. See
      > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
      > for more details.
      > 
      > This problem can be fixed by observing that V8 frames usually all have the same
      > prolog and epilog:
      > 
      > push rbp,
      > mov rbp, rsp
      > ...
      > pop rbp
      > ret N
      > 
      > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
      > should walk through V8 frames. Furthermore, since V8 Code objects are all
      > allocated in the same code-range for an Isolate, it is possible to register a
      > single PDATA/XDATA entry to cover stack walking for all the code generated
      > inside that code-range.
      > 
      > This PR contains changes required to enable stack walking on Win64:
      > 
      > EmbeddedFileWriter now adds assembler directives to the builtins
      > snapshot source file (embedded.cc) to emit additional entries in the .pdata and
      > in the .xdata section of the V8 executable. This takes care of stack walking
      > for embedded builtins. (The case of non-embedded builtins is not supported).
      > The x64 Assembler has been modified to collect the information required to emit
      > this unwind info for builtins.
      > 
      > Stack walking for jitted code is handled is Isolate.cpp, by registering
      > dynamically PDATA/XDATA for the whole code-range address space every time a new
      > Isolate is initialized, and by unregistering them when the Isolate is
      > destroyed.
      > 
      > Stack walking for WASM jitted code is handled is the same way in
      > wasm::NativeModule (wasm/wasm-code-manager.cpp).
      > 
      > It is important to note that Crashpad and Breakpad are already registering
      > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
      > builtins). Since it is not possible to register multiple PDATA entries for the
      > same address range, a new function is added to the V8 API:
      > SetUnhandledExceptionCallback() can be used by an embedder to register its own
      > unhandled exception handler for exceptions that arise in v8-generated code.
      > V8 embedders should be modified accordingly (code for this is in a separate PR
      > in the Chromium repository:
      > https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
      > 
      > All these changes are experimental, behind:
      > 
      > the 'v8_win64_unwinding_info' build flag, and
      > the '--win64-unwinding-info' runtime flag.
      > 
      > Bug: v8:3598
      > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#60330}
      
      Bug: v8:3598
      Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60581}
      969cb0c7
  18. 01 Apr, 2019 1 commit
  19. 28 Mar, 2019 2 commits
  20. 27 Mar, 2019 1 commit
  21. 25 Mar, 2019 2 commits
  22. 22 Mar, 2019 1 commit
  23. 21 Mar, 2019 2 commits
  24. 20 Mar, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "V8 x64 backend doesn't emit ABI compliant stack frames" · 9f6ddb48
      Leszek Swirski authored
      This reverts commit 3cda21de.
      
      Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)
      
      Original change's description:
      > V8 x64 backend doesn't emit ABI compliant stack frames
      > 
      > On 64 bit Windows, the OS stack walking does not work because the V8 x64
      > backend doesn't emit unwinding info and also because it doesn't emit ABI
      > compliant stack frames. See
      > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
      > for more details.
      > 
      > This problem can be fixed by observing that V8 frames usually all have the same
      > prolog and epilog:
      > 
      > push rbp,
      > mov rbp, rsp
      > ...
      > pop rbp
      > ret N
      > 
      > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
      > should walk through V8 frames. Furthermore, since V8 Code objects are all
      > allocated in the same code-range for an Isolate, it is possible to register a
      > single PDATA/XDATA entry to cover stack walking for all the code generated
      > inside that code-range.
      > 
      > This PR contains changes required to enable stack walking on Win64:
      > 
      > EmbeddedFileWriter now adds assembler directives to the builtins
      > snapshot source file (embedded.cc) to emit additional entries in the .pdata and
      > in the .xdata section of the V8 executable. This takes care of stack walking
      > for embedded builtins. (The case of non-embedded builtins is not supported).
      > The x64 Assembler has been modified to collect the information required to emit
      > this unwind info for builtins.
      > 
      > Stack walking for jitted code is handled is Isolate.cpp, by registering
      > dynamically PDATA/XDATA for the whole code-range address space every time a new
      > Isolate is initialized, and by unregistering them when the Isolate is
      > destroyed.
      > 
      > Stack walking for WASM jitted code is handled is the same way in
      > wasm::NativeModule (wasm/wasm-code-manager.cpp).
      > 
      > It is important to note that Crashpad and Breakpad are already registering
      > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
      > builtins). Since it is not possible to register multiple PDATA entries for the
      > same address range, a new function is added to the V8 API:
      > SetUnhandledExceptionCallback() can be used by an embedder to register its own
      > unhandled exception handler for exceptions that arise in v8-generated code.
      > V8 embedders should be modified accordingly (code for this is in a separate PR
      > in the Chromium repository:
      > https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
      > 
      > All these changes are experimental, behind:
      > 
      > the 'v8_win64_unwinding_info' build flag, and
      > the '--win64-unwinding-info' runtime flag.
      > 
      > Bug: v8:3598
      > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#60330}
      
      TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com
      
      Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:3598
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60372}
      9f6ddb48
  25. 19 Mar, 2019 2 commits
    • Deepti Gandluri's avatar
      [wasm-simd] Fix x64 F32x4 ReplaceLane · 1425244f
      Deepti Gandluri authored
      Change-Id: I94ae52c609c591d95ef0f71cba45e25ef80c9a77
      Bug: v8:9008
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529931Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60342}
      1425244f
    • Paolo Severini's avatar
      V8 x64 backend doesn't emit ABI compliant stack frames · 3cda21de
      Paolo Severini authored
      On 64 bit Windows, the OS stack walking does not work because the V8 x64
      backend doesn't emit unwinding info and also because it doesn't emit ABI
      compliant stack frames. See
      https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
      for more details.
      
      This problem can be fixed by observing that V8 frames usually all have the same
      prolog and epilog:
      
      push rbp,
      mov rbp, rsp
      ...
      pop rbp
      ret N
      
      and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
      should walk through V8 frames. Furthermore, since V8 Code objects are all
      allocated in the same code-range for an Isolate, it is possible to register a
      single PDATA/XDATA entry to cover stack walking for all the code generated
      inside that code-range.
      
      This PR contains changes required to enable stack walking on Win64:
      
      EmbeddedFileWriter now adds assembler directives to the builtins
      snapshot source file (embedded.cc) to emit additional entries in the .pdata and
      in the .xdata section of the V8 executable. This takes care of stack walking
      for embedded builtins. (The case of non-embedded builtins is not supported).
      The x64 Assembler has been modified to collect the information required to emit
      this unwind info for builtins.
      
      Stack walking for jitted code is handled is Isolate.cpp, by registering
      dynamically PDATA/XDATA for the whole code-range address space every time a new
      Isolate is initialized, and by unregistering them when the Isolate is
      destroyed.
      
      Stack walking for WASM jitted code is handled is the same way in
      wasm::NativeModule (wasm/wasm-code-manager.cpp).
      
      It is important to note that Crashpad and Breakpad are already registering
      PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
      builtins). Since it is not possible to register multiple PDATA entries for the
      same address range, a new function is added to the V8 API:
      SetUnhandledExceptionCallback() can be used by an embedder to register its own
      unhandled exception handler for exceptions that arise in v8-generated code.
      V8 embedders should be modified accordingly (code for this is in a separate PR
      in the Chromium repository:
      https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
      
      All these changes are experimental, behind:
      
      the 'v8_win64_unwinding_info' build flag, and
      the '--win64-unwinding-info' runtime flag.
      
      Bug: v8:3598
      Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#60330}
      3cda21de
  26. 18 Mar, 2019 2 commits
  27. 15 Mar, 2019 1 commit
  28. 12 Mar, 2019 1 commit