1. 14 Jan, 2019 1 commit
  2. 10 Jan, 2019 2 commits
  3. 12 Dec, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Group anyref parameter · 9f3c996d
      Andreas Haas authored
      To allow any-ref parameters, we have to make sure that any-ref stack
      parameters get seen by the GC. This CL is a first step into that
      direction. The goal of this CL is to group any-ref parameters at the
      stack side of the parameters. This means that in the stack frame
      iterator we do not need information about where anyref parameters are
      in the stack frame. We only need information about how many anyref
      parameters there are at the bottom of the stack frame.
      
      
      R=mstarzinger@chromium.org
      
      Also-By: mstarzinger@chromium.org
      Bug: v8:7581
      Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803
      Reviewed-on: https://chromium-review.googlesource.com/c/1371827
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58184}
      9f3c996d
  4. 11 Dec, 2018 1 commit
  5. 05 Dec, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Load thread-in-wasm flag from the isolate · 148ef606
      Andreas Haas authored
      The existing implementation embedded an isolate-specific pointer to the
      thread-in-wasm flag in the wrapper code. However, when the module code
      is shared among multiple workers, this can mean that the workers
      share the same thread-in-wasm flag.
      
      With this change we load the pointer to the flag at runtime from the
      current isolate. Thereby the correct flag is used even when the same
      code is executed on different workers.
      
      Note that we could access the right flag address by going through the
      root register. However, changing the code generation to use the root
      register requires some inconvenient steps:
      * Pass the isolate to the pipeline again, which we don't want.
      * Change the WasmCallDescriptor to allow the use of the root register
        for wrappers but not for other code.
      To avoid these issues, and allow the CL to be easy to merge back, we
      got for the changes proposed here.
      
      R=mstarzinger@chromium.org, ishell@chromium.org
      
      Bug: v8:8533
      Change-Id: If15565a7ad7cba835cfc1628e7a4d3fdef90a5c0
      Reviewed-on: https://chromium-review.googlesource.com/c/1358518
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58044}
      148ef606
  6. 04 Dec, 2018 3 commits
    • Ben Smith's avatar
      [wasm] Validate memory.init and memory.drop · 216fb648
      Ben Smith authored
      The memory.init and memory.drop instructions have a data segment index
      that can only be validated by knowing the number of data segments. This
      information is provided by the new DataCount section.
      
      Bug: v8:7747
      Change-Id: Ie04d57584fe028637f6e931ab53d00abc5b998a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1355624Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Ben Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58031}
      216fb648
    • Clemens Hammacher's avatar
      Reland "[wasm][liftoff] Optimize one-armed ifs" · 7768b245
      Clemens Hammacher authored
      This is a reland of c2aaf0a6
      
      Original change's description:
      > [wasm][liftoff] Optimize one-armed ifs
      > 
      > Do not implement one-armed ifs by emulating an empty else branch. In
      > Liftoff, we can generate better code and save compile time by handling
      > this specially. If the merge point at the end of the if is not reached
      > by the if-branch, we do not need to generate any merge code.
      > 
      > R=titzer@chromium.org
      > 
      > Bug: v8:6600, v8:8423
      > Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
      > Reviewed-on: https://chromium-review.googlesource.com/c/1356508
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57968}
      
      Bug: v8:6600, v8:8423
      Change-Id: I6d5eea9f860486768779a33bf6bd7b87cbfc2af0
      Reviewed-on: https://chromium-review.googlesource.com/c/1361040Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58024}
      7768b245
    • Clemens Hammacher's avatar
      Revert "[wasm][liftoff] Optimize one-armed ifs" · 0536ee43
      Clemens Hammacher authored
      This reverts commit c2aaf0a6.
      
      Reason for revert: Benchmarks fail, and ClusterFuzz is not happy (issue 911406, issue 911271)
      
      Original change's description:
      > [wasm][liftoff] Optimize one-armed ifs
      > 
      > Do not implement one-armed ifs by emulating an empty else branch. In
      > Liftoff, we can generate better code and save compile time by handling
      > this specially. If the merge point at the end of the if is not reached
      > by the if-branch, we do not need to generate any merge code.
      > 
      > R=​titzer@chromium.org
      > 
      > Bug: v8:6600, v8:8423
      > Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
      > Reviewed-on: https://chromium-review.googlesource.com/c/1356508
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57968}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6600, v8:8423
      Change-Id: I5cb3b069f40e34f34da4013e666f6ff293752567
      Reviewed-on: https://chromium-review.googlesource.com/c/1360633Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58012}
      0536ee43
  7. 30 Nov, 2018 3 commits
  8. 29 Nov, 2018 3 commits
    • Ben Smith's avatar
      [wasm] Parse DataCount section for bulk-memory · cb62c6ed
      Ben Smith authored
      The bulk-memory proposal adds a new DataCount section that declares the
      number of data segments that are expected to be seen in the Data
      section. This is similar to the way the number of functions is split
      between the Function and Code sections.
      
      The DataCount section occurs before the Code section, so we can do
      single-pass validation of the new `memory.init` and `memory.drop`
      instructions, which have data segment indices as immediates.
      
      Bug: v8:7747
      Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00
      Reviewed-on: https://chromium-review.googlesource.com/c/1352792
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57951}
      cb62c6ed
    • Ben Smith's avatar
      [wasm] Fail validation with non-zero functions, but no code section · e79760c9
      Ben Smith authored
      Make sure to check that the number of declared functions (specified in the
      function section) matches the number of function bodies, even if the code
      section is omitted.
      
      Note that it is valid to have a function section with zero declared functions
      and an omitted code section, and vice versa.
      
      Bug: v8:8514
      Change-Id: I4effa5abe2ed6d71146a665d2df6a2f48b5a84be
      Reviewed-on: https://chromium-review.googlesource.com/c/1351306
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57949}
      e79760c9
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  9. 28 Nov, 2018 2 commits
  10. 27 Nov, 2018 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Add more unit tests for trap handler" · 2fd07376
      Clemens Hammacher authored
      This reverts commit 4644b32e.
      
      Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
      
      Original change's description:
      > [wasm] Add more unit tests for trap handler
      > 
      > The unittests test if the trap handler only handles those traps it
      > is supposed to handle:
      > * Only handle traps when the thread-in-wasm flag is set.
      > * Only handle traps of the right type, i.e. memory access violations.
      > * Only handle traps at recorded instructions.
      > 
      > The tests also test the consistency of the thread-in-wasm flag. I made
      > one change in the trap handler where that consistency could be
      > violated.
      > 
      > All tests are executed with the default trap handler provided by V8,
      > and with the trap handler callback installed in a test signal/exception
      > handler.
      > 
      > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57858}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
      
      Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57861}
      2fd07376
    • Andreas Haas's avatar
      [wasm] Add more unit tests for trap handler · 4644b32e
      Andreas Haas authored
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57858}
      4644b32e
  11. 19 Nov, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Decode bulk memory instructions · 50798d60
      Ben Smith authored
      These instructions aren't implemented yet in TF or in Liftoff, but they
      are properly decoded.
      
      The table instructions (i.e. `table.{init,drop,copy}`) are validated,
      since the table and element sections occur before the code section. The
      memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
      validated because the data section occurs after the code section, so it
      can't be verified in one pass (without throwing a validation error
      later).
      
      There is currently a discussion about whether to add a new section
      (similar to `func`) that predefines the number of expected data
      segments. If we add this, then we can validate in one pass. For now,
      we'll leave it unimplemented.
      
      Bug: v8:7747
      Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
      Reviewed-on: https://chromium-review.googlesource.com/c/1339241
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57622}
      50798d60
  12. 14 Nov, 2018 1 commit
  13. 12 Nov, 2018 2 commits
  14. 07 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Decouple wire bytes from compilation units · 014d9e4f
      Clemens Hammacher authored
      Compilation units currently contain pointers into allocated space that
      contains the code of the respective function. This requires us to keep
      the StreamingDecoder alive as long as compilation is still running
      (including tiering).
      This CL refactors this by having an additional redirection
      (WireBytesStorage) which can point to either the StreamingDecoder or
      the NativeModule. We only keep the code section buffer alive as long as
      the StreamingWireBytesStorage is still in use.
      
      I will further refactor memory ownership in a follow-up CL to not make
      the AsyncCompileJob keep the StreamingDecoder alive.
      
      R=ahaas@chromium.org
      
      Bug: v8:8343,v8:7921,v8:8050
      Change-Id: I780582c3217abf64000454f2c9c108b9ac9fbff1
      Reviewed-on: https://chromium-review.googlesource.com/c/1319588Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57317}
      014d9e4f
  15. 30 Oct, 2018 1 commit
  16. 29 Oct, 2018 1 commit
  17. 26 Oct, 2018 1 commit
  18. 25 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmEngine in NativeModule · 69546692
      Clemens Hammacher authored
      The {CompilationState} currently stores the {WasmEngine}, while the
      {NativeModule} only stores the {WasmCodeManager}. From a high-level
      view, this does not make much sense. The {NativeModule} belongs to
      exactly one {WasmEngine}, so that link should be stored there. We can
      then get to the {WasmCodeManager} from the {WasmEngine}.
      
      This change requires a refactoring of the {WasmCodeManagerTest} which
      created {WasmCodeManager}s independent of the {Isolate} and the
      {WasmEngine}. This is not supported any more.
      Note that in production, each {WasmEngine} owns exactly one
      {WasmCodeManager} and one {WasmMemoryTracker}, so testing that a
      {WasmMemoryTracker} can be shared by several {WasmCodeManager}s didn't
      make sense in the first place.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8217
      Change-Id: I582e698be35f97dbd38bf6e12eb7f8ee4fc1f0f2
      Reviewed-on: https://chromium-review.googlesource.com/c/1297960
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56992}
      69546692
  19. 23 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Do not store ModuleEnv · 9716f689
      Clemens Hammacher authored
      Instead, create it when needed and pass it down to the actual
      compilation.
      This saves memory by making the WasmCompilationUnit smaller and will
      eventually allow us to implement the trap handler fallback correctly by
      using an updated ModuleEnv in background compilation and tier up.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:5277, v8:8343
      Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367
      Reviewed-on: https://chromium-review.googlesource.com/c/1293953
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56896}
      9716f689
  20. 22 Oct, 2018 1 commit
  21. 19 Oct, 2018 2 commits
  22. 17 Oct, 2018 6 commits
  23. 16 Oct, 2018 2 commits