1. 05 May, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Complete element segment features for reftypes/typed-funcref · 37579df7
      Manos Koukoutos authored
      Main changes:
      - Allow global.get in elements segments with expressions-as-elements.
      - Allow element segments with types other than funcref.
      
      Detailed changes:
      - Move WasmInitExpr to its own file. Add stream opearator << support.
      - Simplify type of PrintCollection.
      - Make WasmElemSegment use an array of WasmInitExpr's over the previous
        ad-hoc implementation. Move null_index to WasmModuleBuilder.
      - Refactor consume_element_segment_header. Make it return a
        WasmElemSegment.
      - Refactor consume_element_expr. Make it return a WasmInitExpr.
      - Refactor DecodeElementSection. Make it invoke
        consume_element_segment_header, then populate its element array.
      - Update module-instantiate.cc to handle global.get elements.
      - Fix bug in wasm-objects.cc where the wrong type index was passed into
        module()->has_signature()
      - Adapt and add tests.
      
      Change-Id: I5abfbe424dbb750ee2dca59f91c451ffcb79f95f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857959
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74374}
      37579df7
  2. 05 Feb, 2021 1 commit
    • Paolo Severini's avatar
      [compiler] Re-reland "Faster JS-to-Wasm calls" · 831fa62b
      Paolo Severini authored
      This is a reland of 6ada6a90
      
      - Fixed a GC issue
        https://bugs.chromium.org/p/v8/issues/detail?id=11335:
        GC expected all arguments on the stack from code with
        CodeKind::TURBOFAN to be tagged objects. This is not the case now with
        inlined Wasm calls, and this information can be passed in
        SafepointEntry for each call site.
      
      - Disabled JS-to-Wasm inlining for calls inside try/catch.
      
      For more details, see updated doc:
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      
      Bug: v8:11092
      
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests).
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
      > generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72541}
      831fa62b
  3. 22 Jan, 2021 2 commits
    • Jakob Kummerow's avatar
      [wasm-gc] Liftoff support part 6: funcrefs · ec5b796f
      Jakob Kummerow authored
      This implements support for the following instructions:
      ref.func, call_ref, return_call_ref
      
      Bug: v8:7748,v8:9495
      Change-Id: If5bdc2b9bc2347de056de2917430b8d9dc901c53
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632591
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72270}
      ec5b796f
    • Paolo Severini's avatar
      Revert "Reland "Faster JS-to-Wasm calls"" · 51ecfaec
      Paolo Severini authored
      This reverts commit 6ada6a90.
      
      Reason for revert: Revert for link issue:
      https://bugs.chromium.org/p/v8/issues/detail?id=11335
      
      Original change's description:
      > Reland "Faster JS-to-Wasm calls"
      >
      > This is a reland of 860fcb1b
      >
      > - Disabled the tests for this feature in V8-lite mode (the original
      > change broke V8-lite tests)
      > - Also modified test console-profile-wasm.js that was brittle with this
      > change because it assumed that there was always a JS-to-Wasm wrapper
      > but this is not the case when the TurboFan compilation completes before
      > the Liftoff-compiled code starts to run.
      >
      > More changes in Patchset 8:
      >
      > - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      > into a new phase, wasm-inlining that reuses the JSInliner reducer.
      > The doc
      > https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      > describes the new logic.
      >
      > - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      > the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      > this should solve the problem we had inlining the calls in functions
      > that can throw exception.
      >
      >
      > Original change's description:
      > > Faster JS-to-Wasm calls
      > >
      > > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      > >
      > > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > > the basis of the signature of a Wasm function to call, and whose task
      > > is to:
      > > - set "thread_in_wasm_flag" to true
      > > - convert the arguments from tagged types into Wasm native types
      > > - calculate the address of the Wasm function to call and call it
      > > - convert back the result from Wasm native types into tagged types
      > > - reset "thread_in_wasm_flag" to false.
      > >
      > > This CL tries to improve the performance of JS-to-Wasm calls by
      > > inlining the code of the JS-to-Wasm wrappers in the call site.
      > >
      > > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > > this kind of calls. A 'JSWasmCall' node is associated to
      > > WasmCallParameters, which contain information about the signature of
      > > the Wasm function to call.
      > >
      > > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > > of the Wasm function, when the conversion is not necessary.
      > > The actual inlining of the graph generated for this wrapper happens in
      > > the simplified-lowering phase.
      > >
      > > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > > lazy deoptimizations that can happen if the Wasm function callee calls
      > > back some JS code that invalidates the compiled JS caller function.
      > >
      > > Bug: v8:11092
      > > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > > Cr-Commit-Position: refs/heads/master@{#71824}
      >
      > Bug: v8:11092
      > Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      > Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72147}
      
      Tbr: ahaas@chromium.org, jgruber@chromium.org
      Bug: v8:11092, v8:11335
      Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72253}
      51ecfaec
  4. 19 Jan, 2021 1 commit
    • Paolo Severini's avatar
      Reland "Faster JS-to-Wasm calls" · 6ada6a90
      Paolo Severini authored
      This is a reland of 860fcb1b
      
      - Disabled the tests for this feature in V8-lite mode (the original
      change broke V8-lite tests)
      - Also modified test console-profile-wasm.js that was brittle with this
      change because it assumed that there was always a JS-to-Wasm wrapper
      but this is not the case when the TurboFan compilation completes before
      the Liftoff-compiled code starts to run.
      
      More changes in Patchset 8:
      
      - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
      into a new phase, wasm-inlining that reuses the JSInliner reducer.
      The doc
      https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
      describes the new logic.
      
      - Fixed a couple of small issues in wasm_compiler.cc to make sure that
      the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
      this should solve the problem we had inlining the calls in functions
      that can throw exception.
      
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      Bug: v8:11092
      Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
      Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72147}
      6ada6a90
  5. 17 Dec, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "Faster JS-to-Wasm calls" · de50785e
      Nico Hartmann authored
      This reverts commit 860fcb1b.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20lite/13831/overview
      
      Original change's description:
      > Faster JS-to-Wasm calls
      >
      > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      >
      > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      > the basis of the signature of a Wasm function to call, and whose task
      > is to:
      > - set "thread_in_wasm_flag" to true
      > - convert the arguments from tagged types into Wasm native types
      > - calculate the address of the Wasm function to call and call it
      > - convert back the result from Wasm native types into tagged types
      > - reset "thread_in_wasm_flag" to false.
      >
      > This CL tries to improve the performance of JS-to-Wasm calls by
      > inlining the code of the JS-to-Wasm wrappers in the call site.
      >
      > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      > this kind of calls. A 'JSWasmCall' node is associated to
      > WasmCallParameters, which contain information about the signature of
      > the Wasm function to call.
      >
      > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      > of the Wasm function, when the conversion is not necessary.
      > The actual inlining of the graph generated for this wrapper happens in
      > the simplified-lowering phase.
      >
      > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      > lazy deoptimizations that can happen if the Wasm function callee calls
      > back some JS code that invalidates the compiled JS caller function.
      >
      > Bug: v8:11092
      > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#71824}
      
      TBR=neis@chromium.org,ahaas@chromium.org,jgruber@chromium.org,tebbi@chromium.org,ishell@chromium.org,mslekova@chromium.org,nicohartmann@chromium.org,paolosev@microsoft.com
      
      Change-Id: I214cbdee74c1a2aaad907ffc84662ed25631983e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:11092
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595438Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71825}
      de50785e
    • Paolo Severini's avatar
      Faster JS-to-Wasm calls · 860fcb1b
      Paolo Severini authored
      This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
      
      Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
      the basis of the signature of a Wasm function to call, and whose task
      is to:
      - set "thread_in_wasm_flag" to true
      - convert the arguments from tagged types into Wasm native types
      - calculate the address of the Wasm function to call and call it
      - convert back the result from Wasm native types into tagged types
      - reset "thread_in_wasm_flag" to false.
      
      This CL tries to improve the performance of JS-to-Wasm calls by
      inlining the code of the JS-to-Wasm wrappers in the call site.
      
      It introduces a new IR operand, JSWasmCall, which replaces JSCall for
      this kind of calls. A 'JSWasmCall' node is associated to
      WasmCallParameters, which contain information about the signature of
      the Wasm function to call.
      
      WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
      of the Wasm function, when the conversion is not necessary.
      The actual inlining of the graph generated for this wrapper happens in
      the simplified-lowering phase.
      
      A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
      lazy deoptimizations that can happen if the Wasm function callee calls
      back some JS code that invalidates the compiled JS caller function.
      
      Bug: v8:11092
      Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarGeorg Neis (ooo until January 5) <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Paolo Severini <paolosev@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71824}
      860fcb1b
  6. 16 Dec, 2020 1 commit
  7. 16 Nov, 2020 1 commit
    • Jakob Kummerow's avatar
      [wasm-gc] Fix several bugs · 7e533de1
      Jakob Kummerow authored
      - allow arrays to be allocated in LargeObjectSpace
      - check requested array allocation length against maximum
      - fix array element offsets for pointer-typed elements
      - fix GC handling of arrays when there are forwarding pointers
      - module builder: fix rtt.sub global initializer expressions
      - debug printing: print "UNIMPLEMENTED" instead of crashing
      - WasmGCTester: make some exceptions easier to diagnose
      
      Bug: v8:7748, chromium:1141376
      Change-Id: Ie0281658748f3dd5e5d90d85bab78f0ea2fc3865
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534815Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71208}
      7e533de1
  8. 22 Oct, 2020 1 commit
    • Manos Koukoutos's avatar
      Reland "[wasm-gc] Implement call_ref on WasmJSFunction" · 40ad9116
      Manos Koukoutos authored
      This is a reland of 6227c95e
      
      Fixes compared to original landing:
      - Decode a WASM_TO_JS_FUNCTION Code object as a WASM_TO_JS frame.
      - Enable call_ref on WasmJSFunctions with arity mismatch.
      - Use builtin pointer in BuildWasmToJSWrapper, to avoid having to
        resolve the relocatable constant.
      
      Original change's description:
      > [wasm-gc] Implement call_ref on WasmJSFunction
      >
      > Changes:
      > - Introduce turbofan builtin WasmAllocatePair.
      > - Implement call_ref for WasmJSFunction in wasm-compiler.cc.
      > - Remove WasmJSFunction trap.
      > - Improve and extend call-ref.js test.
      >
      > Bug: v8:9495
      > Change-Id: I8b4d1ab70cbbe9ae37887a6241d409eec638fd28
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463226
      > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70535}
      
      Bug: v8:9495
      Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
      Change-Id: I294947059e612d417d92614a43cb7383cd5f3b92
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476314
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70719}
      40ad9116
  9. 15 Oct, 2020 2 commits
  10. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  11. 21 Jul, 2020 2 commits
  12. 19 May, 2020 1 commit
  13. 13 May, 2020 1 commit
  14. 11 May, 2020 1 commit
  15. 09 May, 2020 1 commit
  16. 08 May, 2020 1 commit
  17. 06 May, 2020 2 commits
  18. 05 May, 2020 1 commit
  19. 04 May, 2020 2 commits
  20. 29 Apr, 2020 1 commit
  21. 23 Apr, 2020 2 commits
  22. 21 Apr, 2020 2 commits
  23. 23 Mar, 2020 1 commit
  24. 19 Mar, 2020 2 commits
    • Andreas Haas's avatar
      [wasm] Introduce a TableCopy builtin · 1e1d4d82
      Andreas Haas authored
      This CL introduces a CSA builtin for the TableCopy instruction. This
      builtin allows to generate smaller code for both TurboFan and Liftoff,
      and easier code generation from Liftoff.
      
      The smaller code size comes from:
      * Parameters are passed through registers, not the stack.
      * Lower number of parameters: the call target, number of parameters, and
      context are not passed as parameters.
      * No int to smi conversion in generated code.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I4734b94c8a2aff08a5938504e3e36d0d2424f8ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110010
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66797}
      1e1d4d82
    • Andreas Haas's avatar
      [wasm] Introduce a WasmTableInit CSA builtin · ca5ee9d6
      Andreas Haas authored
      This CL introduces a CSA builtin for the TableInit instruction. This
      builtin allows to generate smaller code for both TurboFan and Liftoff,
      and easier code generation from Liftoff.
      
      The smaller code size comes from:
      * Parameters are passed through registers, not the stack.
      * Lower number of parameters: the call target, number of parameters, and
      context are not passed as parameters.
      * No int to smi conversion in generated code.
      
      The CL also introduces a small CSA function which takes an uint32 value
      and a max value as parameters and returns a Smi of the minimum of these
      two.
      
      R=clemensb@chromium.org, ishell@chromium.org
      
      Bug: v8:10281
      Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66792}
      ca5ee9d6
  25. 02 Mar, 2020 1 commit
    • Andreas Haas's avatar
      Reland "[wasm] Refactor AtomicWait implementation" · 7ad6b04e
      Andreas Haas authored
      Stack parameters in the StubCallDescriptor were set to the wrong type. I
      changed it now so that for stack parameters that are specified in the
      CallInterfaceDescriptor, type specified type is used. All other
      parameters are assumed to be tagged, as it has been until now.
      
      Original change's description:
      > [wasm] Refactor AtomicWait implementation
      >
      > The existing implementation included aspects that are not
      > straight-forward to implement in Liftoff and seemed inefficient:
      > * Convert the timeout in WebAssembly code from I64 to F64, just to
      >   convert it back in the runtime.
      >   * On 32-bit platforms this conversion needs an additional C-call.
      > * Split the I64 expected value from I64 into two I32 values in the
      >   wasm-compiler.
      >   * Ideally the int64-lowering takes care of 32-bit specific handling.
      >
      > With this CL the timeout and the expected value are passed as I64 to
      > the runtime (a builtin moves the I64 into a bigint for that). The
      > int64-lowering takes care of 32-bit platforms. There are special
      > builtins for 32-bit platforms, but they are written such that ideally
      > also the int64-lowering could create them.
      
      Bug: v8:10108
      Change-Id: Ib87b543666708457c0d686208a86e46cdca3f9a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080362Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66533}
      7ad6b04e
  26. 28 Feb, 2020 2 commits
    • Sathya Gunasekaran's avatar
      Revert "[wasm] Refactor AtomicWait implementation" · 9945e908
      Sathya Gunasekaran authored
      This reverts commit 77d4e230.
      
      Reason for revert: verify csa build bot broken
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/16218?
      
      Original change's description:
      > [wasm] Refactor AtomicWait implementation
      > 
      > The existing implementation included aspects that are not
      > straight-forward to implement in Liftoff and seemed inefficient:
      > * Convert the timeout in WebAssembly code from I64 to F64, just to
      >   convert it back in the runtime.
      >   * On 32-bit platforms this conversion needs an additional C-call.
      > * Split the I64 expected value from I64 into two I32 values in the
      >   wasm-compiler.
      >   * Ideally the int64-lowering takes care of 32-bit specific handling.
      > 
      > With this CL the timeout and the expected value are passed as I64 to
      > the runtime (a builtin moves the I64 into a bigint for that). The
      > int64-lowering takes care of 32-bit platforms. There are special
      > builtins for 32-bit platforms, but they are written such that ideally
      > also the int64-lowering could create them.
      > 
      > R=​jkummerow@chromium.org, binji@chromium.org
      > 
      > Bug: v8:10108
      > Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Ben Smith <binji@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66497}
      
      TBR=binji@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org
      
      Change-Id: If284aa07eedddd2fbea4df8c53c7d371cac1d42e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10108
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080250Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66498}
      9945e908
    • Andreas Haas's avatar
      [wasm] Refactor AtomicWait implementation · 77d4e230
      Andreas Haas authored
      The existing implementation included aspects that are not
      straight-forward to implement in Liftoff and seemed inefficient:
      * Convert the timeout in WebAssembly code from I64 to F64, just to
        convert it back in the runtime.
        * On 32-bit platforms this conversion needs an additional C-call.
      * Split the I64 expected value from I64 into two I32 values in the
        wasm-compiler.
        * Ideally the int64-lowering takes care of 32-bit specific handling.
      
      With this CL the timeout and the expected value are passed as I64 to
      the runtime (a builtin moves the I64 into a bigint for that). The
      int64-lowering takes care of 32-bit platforms. There are special
      builtins for 32-bit platforms, but they are written such that ideally
      also the int64-lowering could create them.
      
      R=jkummerow@chromium.org, binji@chromium.org
      
      Bug: v8:10108
      Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66497}
      77d4e230
  27. 28 Nov, 2019 2 commits
  28. 20 Nov, 2019 1 commit
  29. 08 Nov, 2019 1 commit