1. 12 Jan, 2017 5 commits
  2. 11 Jan, 2017 11 commits
    • clemensh's avatar
      [wasm] Add support for compiling WASM_INTERPRETER_ENTRY stubs · a2efde46
      clemensh authored
      Also, add a runtime function to call the interpreter, passing a
      stack-allocated buffer holding the arguments.
      The WASM_INTERPRETER_ENTRY stub allocates the stack slot for the
      arguments, fills it, and calls to the wasm interpreter.
      It's abi is compatible with WASM functions, such that we can just
      replace a call to a WASM_FUNCTION with a call to
      WASM_INTERPRETER_ENTRY.
      See tracking bug to get the overall picture.
      
      BUG=v8:5822
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2619803004
      Cr-Commit-Position: refs/heads/master@{#42242}
      a2efde46
    • clemensh's avatar
      [compiler] Allow for StackSlots of arbitrary size · 7a3366fb
      clemensh authored
      This will be used to pass parameters of wasm functions to the wasm
      interpreter. All of them need to be packed into one buffer, which is
      then passed to the interpreter.
      
      R=ahaas@chromium.org, titzer@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2624183002
      Cr-Commit-Position: refs/heads/master@{#42239}
      7a3366fb
    • ahaas's avatar
      [wasm] (To|From)JSWrappers with I64 params throw a TypeError upon call. · e9048949
      ahaas authored
      According to the latest spec changes the WasmToJS wrapper and the
      JSToWasm wrapper through a TypeError if the signature of the wrapper
      contains a I64 parameter or return value. Originally the TypeError was
      thrown when the parameter or return value was converted to or from JS.
      
      In addition I removed all special handling of I64 parameters and return
      values in the wrappers which was already dead code.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2626853003
      Cr-Commit-Position: refs/heads/master@{#42238}
      e9048949
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on mips64. · b2d67f3b
      ahaas authored
      Original commit message:
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org, v8-mips-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2627003002
      Cr-Commit-Position: refs/heads/master@{#42237}
      b2d67f3b
    • jkummerow's avatar
      Internalize strings in-place (reland^2) · ec45e6ed
      jkummerow authored
      using newly introduced ThinStrings, which store a pointer to the actual,
      internalized string they represent.
      
      BUG=v8:4520
      
      (Previously landed as #42168 / af51befe)
      (Previously landed as #42193 / 4c699e34)
      
      Review-Url: https://codereview.chromium.org/2549773002
      Cr-Commit-Position: refs/heads/master@{#42235}
      ec45e6ed
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on mips. · b16febbc
      ahaas authored
      Original commit message:
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org, v8-mips-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2628433004
      Cr-Commit-Position: refs/heads/master@{#42230}
      b16febbc
    • mstarzinger's avatar
      [turbofan] Graph building is independent of closure. · fc241b90
      mstarzinger authored
      This changes the BytecodeGraphBuilder interface to make the fact that
      graph construction is independent of a closure explicit. A valid graph
      can be constructed by providing only the pair of statically known values
      for SharedFunctionInfo and TypeFeedbackVector. This is in preparation of
      inlining based on the SharedFunctionInfo.
      
      R=jarin@chromium.org
      BUG=v8:2206
      
      Review-Url: https://codereview.chromium.org/2626623002
      Cr-Commit-Position: refs/heads/master@{#42224}
      fc241b90
    • clemensh's avatar
      [wasm] Introduce WasmToInterpreterFrame · 81700ddf
      clemensh authored
      and rename WasmFrame to WasmCompiledFrame.
      The WasmToInterpreterFrames are not used yet; this will follow in a
      follow-up CL (see tracking bug for the overall picture).
      Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
      call from wasm code to the wasm interpreter, implemented in C++.
      They will support the Summarize method to inspect the stack frames in
      the wasm interpreter.
      
      R=yangguo@chromium.org, titzer@chromium.org
      BUG=v8:5822
      
      Review-Url: https://codereview.chromium.org/2623773004
      Cr-Commit-Position: refs/heads/master@{#42213}
      81700ddf
    • jkummerow's avatar
      Revert of Internalize strings in-place (patchset #17 id:320001 of... · 7ef86f80
      jkummerow authored
      Revert of Internalize strings in-place (patchset #17 id:320001 of https://codereview.chromium.org/2549773002/ )
      
      Reason for revert:
      blocks roll, see: https://codereview.chromium.org/2628733002/
      
      Debug mode runs into an Abort("External string expected, but not found").
      
      Original issue's description:
      > Internalize strings in-place (reland)
      >
      > using newly introduced ThinStrings, which store a pointer to the actual,
      > internalized string they represent.
      >
      > BUG=v8:4520
      >
      > (Previously landed as #42168 / af51befe.
      >
      > Review-Url: https://codereview.chromium.org/2549773002
      > Cr-Commit-Position: refs/heads/master@{#42193}
      > Committed: https://chromium.googlesource.com/v8/v8/+/4c699e349a4986b28574b3a51e8780e3a3d067b1
      
      TBR=ishell@chromium.org,hpayer@chromium.org,bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4520
      
      Review-Url: https://codereview.chromium.org/2625073002
      Cr-Commit-Position: refs/heads/master@{#42212}
      7ef86f80
    • franzih's avatar
      [turbofan] Use feedback from StoreDataPropertyInLiteral. · 088df4e1
      franzih authored
      Lower StoreDataPropertyInLiteral() when storing
      computed property names in object literals.
      
      Add a new AccessMode, kStoreInLiteral. It is similar to
      AccessMode::kStore but does not look
      up properties on the prototype chain.
      
      99% of all literal definitions with computed property names
      end up with generic access_info because of how we count
      properties. Once we fix
      https://bugs.chromium.org/p/v8/issues/detail?id=5625,
      they'll get lowered as well.
      
      BUG=v8:5624
      
      Review-Url: https://codereview.chromium.org/2619773002
      Cr-Commit-Position: refs/heads/master@{#42210}
      088df4e1
    • zhengxing.li's avatar
      X87: [wasm] Prerequisites for WebAssembly Table.Grow. · f5631ead
      zhengxing.li authored
        port 0c4b8ff4 (r42192)
      
        original commit message:
         - Refactor Dispatch tables to have separate function, signature tables
         - New Relocation type for WasmFunctionTableReference, assembler, compiler support.
         - RelocInfo helper functions for Wasm references
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2623133002
      Cr-Commit-Position: refs/heads/master@{#42208}
      f5631ead
  3. 10 Jan, 2017 10 commits
  4. 09 Jan, 2017 9 commits
  5. 06 Jan, 2017 1 commit
  6. 05 Jan, 2017 4 commits