1. 24 Apr, 2018 1 commit
  2. 20 Apr, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Simplify C calls · 8d2d0513
      Clemens Hammacher authored
      Instead of passing multiple pointers to input and output, or to two
      input values, just pass one pointer which holds all inputs and where
      the output is written.
      This also reduces the size of generated Turbofan graphs, since only one
      stack slot is needed and less arguments are passed to the call.
      It also fixes undefined behaviour, since we were passing a pointer e.g.
      as {uint64_t*}, but accessed it using {ReadUnalignedValue}. Now we pass
      an Address, which does not have any alignment constraints.
      
      R=ahaas@chromium.org
      
      Bug: v8:3770, v8:6600
      Change-Id: I54ef80b7e27f77587a9062560c0b3e01d6593e6d
      Reviewed-on: https://chromium-review.googlesource.com/1019147
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52702}
      8d2d0513
  3. 02 Feb, 2018 1 commit
  4. 12 Jan, 2018 1 commit
  5. 04 Oct, 2017 1 commit
  6. 15 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      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
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  7. 20 Jul, 2016 1 commit
  8. 21 Apr, 2016 1 commit
    • ahaas's avatar
      [wasm] New implementation of popcnt and ctz. · b4889f7d
      ahaas authored
      This patch provides a new implementation of popcnt and ctz in the case
      where the platform does not provide these instructions. Instead of
      building a TF graph which implements it we now call a C function.
      
      Additionally I turned on additional tests in test-run-wasm-64.cc
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1857363003
      
      Cr-Commit-Position: refs/heads/master@{#35685}
      b4889f7d
  9. 06 Apr, 2016 1 commit
    • ahaas's avatar
      [wasm] Refactoring of wasm-external-refs. · a7d3e24f
      ahaas authored
      1) I moved the implementations of the wrapper functions into a new cc
      file so that I can use these wrapper functions in tests.
      
      2) I made a generic test for all tests in
      test-run-calls-to-external-references.cc. In the new test we only
      compare the result of a function call through an external reference with
      the result of a direct function call. This is sufficient because we only
      want to test function calls through external references work here.
      The implementation of these functions are tested somewhere else.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1853123002
      
      Cr-Commit-Position: refs/heads/master@{#35289}
      a7d3e24f
  10. 15 Mar, 2016 1 commit
    • ahaas's avatar
      [wasm] Int64Lowering of I64Div and I64Rem. · 29e0e8e9
      ahaas authored
      On 32-bit systems these instructions are compiled to calls to
      C functions. The TF node for the function call is already generated in
      the wasm compiler, the lowering of the I64 parameters is done in the
      Int64Lowering. We use the return value of the C function to determine
      whether the calculation should trap or not.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1804513002
      
      Cr-Commit-Position: refs/heads/master@{#34768}
      29e0e8e9
  11. 14 Mar, 2016 1 commit
    • ahaas's avatar
      [wasm] Int64Lowering of I64XConvertFXX instructions. · d57d14b9
      ahaas authored
      On 32-bit systems I64XConvertFXX instructions are compiled to calls to
      C functions. The TF node for the function call is already generated in
      the wasm compiler, the lowering of the I64 parameter is done in the
      Int64Lowering. We use the return value of the C function to determine
      whether the conversion should trap or not.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1775903002
      
      Cr-Commit-Position: refs/heads/master@{#34738}
      d57d14b9
  12. 04 Mar, 2016 1 commit