1. 30 Jan, 2019 1 commit
  2. 25 Oct, 2017 1 commit
  3. 16 Oct, 2017 1 commit
  4. 18 Apr, 2017 1 commit
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 71cf4890
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Original-Commit-Position: refs/heads/master@{#44592}
      Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44669}
      71cf4890
  5. 12 Apr, 2017 2 commits
    • hablich's avatar
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6... · d3f1d5c5
      hablich authored
      Revert of [wasm] instantiate expressed in terms of compile (patchset #6 id:140001 of https://codereview.chromium.org/2806073002/ )
      
      Reason for revert:
      Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
      
      Original issue's description:
      > [wasm] instantiate expressed in terms of compile
      >
      > Today, the semantics of:
      >
      > WebAssembly.instantiate
      >
      > and
      >
      > WebAssembly.compile().then(new WebAssemblyInstance)
      >
      > are subtly different, to the point where attempting the proposed
      > change uncovered bugs.
      >
      > In the future, it's possible that .instantiate actually have different
      > semantics - if we pre-specialized to the provided ffi, for example.
      > Right now that's not the case.
      >
      > This CL:
      > - gets our implementation closer to what developers may write using
      > the compile -> new Instance alternative, in particular wrt promise
      > creation. By reusing code paths, we uncover more bugs, and keep
      > maintenance cost lower.
      >
      > - it gives us the response-based WebAssembly.instantiate implicitly.
      > Otherwise, we'd need that same implementation on the blink side. The
      > negative is maintenance: imagine if the bugs I mentioned could only be
      > found when running in Blink.
      >
      > BUG=chromium:697028
      >
      > Review-Url: https://codereview.chromium.org/2806073002
      > Cr-Commit-Position: refs/heads/master@{#44592}
      > Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
      
      TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2810203002
      Cr-Commit-Position: refs/heads/master@{#44614}
      d3f1d5c5
    • mtrofin's avatar
      [wasm] instantiate expressed in terms of compile · 7829af32
      mtrofin authored
      Today, the semantics of:
      
      WebAssembly.instantiate
      
      and
      
      WebAssembly.compile().then(new WebAssemblyInstance)
      
      are subtly different, to the point where attempting the proposed
      change uncovered bugs.
      
      In the future, it's possible that .instantiate actually have different
      semantics - if we pre-specialized to the provided ffi, for example.
      Right now that's not the case.
      
      This CL:
      - gets our implementation closer to what developers may write using
      the compile -> new Instance alternative, in particular wrt promise
      creation. By reusing code paths, we uncover more bugs, and keep
      maintenance cost lower.
      
      - it gives us the response-based WebAssembly.instantiate implicitly.
      Otherwise, we'd need that same implementation on the blink side. The
      negative is maintenance: imagine if the bugs I mentioned could only be
      found when running in Blink.
      
      BUG=chromium:697028
      
      Review-Url: https://codereview.chromium.org/2806073002
      Cr-Commit-Position: refs/heads/master@{#44592}
      7829af32
  6. 09 Jan, 2017 1 commit
  7. 29 Apr, 2016 1 commit
    • titzer's avatar
      [wasm] Binary 11: Bump module version to 0xB. · ee03b721
      titzer authored
      [wasm] Binary 11: Swap the order of section name / section length.
      [wasm] Binary 11: Shorter section names.
      [wasm] Binary 11: Add a prefix for function type declarations.
      [wasm] Binary 11: Function types encoded as pcount, p*, rcount, r*
      [wasm] Fix numeric names for functions.
      
      R=rossberg@chromium.org,jfb@chromium.org,ahaas@chromium.org
      BUG=chromium:575167
      LOG=Y
      
      Review-Url: https://codereview.chromium.org/1896863003
      Cr-Commit-Position: refs/heads/master@{#35897}
      ee03b721
  8. 07 Mar, 2016 1 commit
  9. 28 Feb, 2016 1 commit
  10. 03 Feb, 2016 1 commit
  11. 12 Jan, 2016 1 commit
  12. 17 Dec, 2015 1 commit
  13. 11 Dec, 2015 1 commit
    • titzer's avatar
      Initial import of v8-native WASM. · 4c5b3609
      titzer authored
      As discussed in person, this adds the code from v8-native-prototype into
      V8 proper, guarded by GYP flags that do not build the code by default.
      Passing wasm=on to 'make' or setting v8_wasm as a GYP flag activates
      building of this code.
      
      An additional header file is added to and exported from the compiler
      directory, src/compiler/wasm-compiler.h. This exposes a limited interface
      with opaque Node and Graph types to the decoder to build TF graphs, as
      well as functions to compile WASM graphs.
      
      The mjsunit tests added are blacklisted because they fail without the
      WASM object exposed to JS, which is also disabled by the build config
      option.
      
      This corresponds closely to https://github.com/WebAssembly/v8-native-prototype/commit/5981e06ebc9b1e578831d03100f17ebb77970ee0, with some formatting fixes and moving some files into src/compiler.
      
      R=mstarzinger@chromium.org, bradnelson@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1504713014
      
      Cr-Commit-Position: refs/heads/master@{#32794}
      4c5b3609