1. 15 Feb, 2019 1 commit
  2. 13 Feb, 2019 1 commit
  3. 12 Feb, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Generate code for the table.get and table.set instructions · 01dc5707
      Andreas Haas authored
      This CL contains the following changes:
      (1) Allocate memory for WasmTables in the WasmInstance.
          - We extend the WasmInstance by a FixedArray which stores
            references to the WasmTables.
      (2) Rename the name of the backing store of WasmTables from `functions`
          to `elements`.
          - The name `functions` just does not fit anyref tables.
      (3) Generate code with TurboFan for table.get and table.set.
      (4) Extend wasm-module-builder.js to be able to generate modules with
          multiple tables.
      (5) Add  mjsunit tests to test table.get and table.set.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I44af4838ee7a37b394841a2f673ecae5734a4d1c
      Reviewed-on: https://chromium-review.googlesource.com/c/1463519
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59529}
      01dc5707
  4. 23 Jan, 2019 1 commit
  5. 15 Jan, 2019 1 commit
    • Ben L. Titzer's avatar
      [wasm] Implement table.drop · 97cdf35f
      Ben L. Titzer authored
      The table.drop bytecode "drops" the backing storage for an element
      initializer. In the V8 implementation, this is a nop, other than
      updating a per-instance boolean array so that two drops of the same
      segment or a drop of an active segment will trap.
      
      This is implemented with inline code in TurboFan in order to be symmetric
      to memory.drop, but could as easily be a runtime call to be supported in
      Liftoff.
      
      R=mstarzinger@chromium.org
      CC=​binji@chromium.org
      BUG=v8:7747
      
      Change-Id: Ic017398eaa764dd3a9ff19523453ff7142c9abf6
      Reviewed-on: https://chromium-review.googlesource.com/c/1408996Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58817}
      97cdf35f
  6. 09 Jan, 2019 1 commit
  7. 08 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Allow anyref values in WebAssembly.Global objects · 741f2312
      Andreas Haas authored
      This CL adds support for anyref in WebAssembly.Global objects. Note
      that the specification is not complete yet in this area.
      
      I did the following changes:
      - I renamed the `array_buffer` field of WasmGlobalObject to
        `untagged_buffer`
      - I added an additional field of type FixedArray, `tagged_buffer`.
        - In the constructor of WasmGlobalObject I allocate either the former
          or the latter, but not both.
      - In the WebAssembly.Global constructor I added special handling for
        the case where no initial value is provided. In that case I set the
        inital value to `null` and not to `undefined`.
      
      R=titzer@chromium.org
      
      Bug: v8:7581
      Change-Id: I7e4855d7e6c04a9bcdc7ebd450caca5819d060e2
      Reviewed-on: https://chromium-review.googlesource.com/c/1398226
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58625}
      741f2312
  8. 20 Dec, 2018 1 commit
  9. 19 Dec, 2018 1 commit
  10. 18 Dec, 2018 5 commits
  11. 17 Dec, 2018 4 commits
  12. 14 Dec, 2018 1 commit
  13. 12 Dec, 2018 1 commit
    • Ben Smith's avatar
      [wasm] Implement memory.init and memory.drop · 4084185b
      Ben Smith authored
      `memory.init` copies bytes from a passive data segment to linear memory.
      
      `memory.drop` is an instruction that informs the wasm VM that the instance no
      longer needs access to the passive data segment.
      
      Information about the passive data segments, including their contents, length,
      and whether they are dropped, is stored in the `WasmInstanceObject` as primitive
      arrays.
      
      Bug: v8:7747
      Change-Id: I1515c8868c9be227743456a539126c15280b5365
      Reviewed-on: https://chromium-review.googlesource.com/c/1370691Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Ben Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58196}
      4084185b
  14. 11 Dec, 2018 1 commit
  15. 08 Dec, 2018 1 commit
  16. 03 Dec, 2018 1 commit
  17. 29 Nov, 2018 1 commit
  18. 25 Nov, 2018 1 commit
  19. 24 Nov, 2018 1 commit
  20. 23 Nov, 2018 1 commit
  21. 21 Nov, 2018 1 commit
    • Ross McIlroy's avatar
      [AsmJs] Avoid allocation of WasmModuleObject until instantiation. · ccd8073c
      Ross McIlroy authored
      Moves allocation of the WasmModuleObject for asm.js code out of SyncCompileTranslatedAsmJS
      since that is called when we are compiling the native context independent SharedFunctionInfo
      and the WasmModuleObject requires a native context. Instead save the members required to
      create the object in the AsmWasmData and create it during module instantiation. Note:
      since the Wasm module is an implementation detail for asm_wasm code and isn't exposed,
      this doeesn't have semantic change for asm.js code.
      
      As part of this change, the AsmWasmData is changed from a FixedArray to a dedicated
      struct. Some logic is also moved from module-compiler to wasm-engine to make the
      seperation between Wasm SyncCompile and AsmJS SyncCompile more clear.
      
      BUG=chromium:900535,v8:8395
      
      Change-Id: Ia48469c095b0688f210aa86e7430c9ab4ea4b26b
      Reviewed-on: https://chromium-review.googlesource.com/c/1345509
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57704}
      ccd8073c
  22. 12 Nov, 2018 1 commit
  23. 25 Oct, 2018 1 commit
  24. 10 Oct, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Use a tuple as the instance for JS imports · a2b34806
      Ben L. Titzer authored
      This CL refactors the implementation of WASM->JS import wrappers in order
      to make the wrapper code shareable. Instead of specializing to the import
      index, we use a tuple as the object ref in the both the import and indirect
      tables. The tuple allows the wrapper code to load both the calling
      instance and the target callable, rather than relying on code specialization.
      
      This requires some tricky codegen machinery, because WASM call descriptors
      expect an instance argument in a given register, yet the wrappers receive
      a tuple, the code generator must generate a prologue that loads the
      instance (and the callable), since it is not possible to express this at
      the graph level.
      
      R=mstarzinger@chromium.org
      CC=clemensh@chromium.org
      
      Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
      Reviewed-on: https://chromium-review.googlesource.com/c/1268237
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56520}
      a2b34806
  25. 17 Sep, 2018 3 commits
  26. 13 Sep, 2018 2 commits
  27. 11 Sep, 2018 1 commit
  28. 10 Sep, 2018 1 commit
  29. 21 Aug, 2018 1 commit
  30. 17 Aug, 2018 1 commit