Skip to content

V
V8
Switch branch/tag
  1. 21 Dec, 2016 1 commit
  3. 15 Dec, 2016 2 commits
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32. · f435d622
      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

Review-Url: https://codereview.chromium.org/2571813002
Cr-Commit-Position: refs/heads/master@{#41735}
      f435d622
    • 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
  5. 26 Oct, 2016 1 commit
  7. 12 Sep, 2016 1 commit
  9. 08 Sep, 2016 1 commit
  11. 02 Sep, 2016 1 commit
    • gdeepti's avatar
      [wasm] Fix wasm decoder tracing for prefix opcodes. · eed164b3
      gdeepti authored 
      Using --trace-wasm-decoder prints unknowns for prefix opcodes, example:

  @3      #01:Block               |  env = 0x5547c10, state = R, reason = block:start, control = #0:Start

  @4      #14:GetLocal            | i@4:GetLocal[0]
  @6      #e5:Unknown             | s@6:Unknown
  @8      #15:SetLocal            | s@8:SetLocal[1]
  @10     #14:GetLocal            | s@8:SetLocal[1] i@10:GetLocal[0]
  @12     #14:GetLocal            | s@8:SetLocal[1] i@10:GetLocal[0] s@12:GetLocal[1]
  @14     #cb:I8Const             | s@8:SetLocal[1] i@10:GetLocal[0] s@12:GetLocal[1] i@14:I8Const
  @16     #e5:Unknown             | s@8:SetLocal[1] i@10:GetLocal[0] i@16:Unknown

Fixed to print:

  @3        #01:Block               |  env = 0x45cac10, state = R, reason = block:start, control = #0:Start

  @4        #14:GetLocal            | i@4:GetLocal[0]
  @6    #e5 #1b:I32x4Splat          | s@6:I32x4Splat
  @8        #15:SetLocal            | s@8:SetLocal[1]
  @10       #14:GetLocal            | s@8:SetLocal[1] i@10:GetLocal[0]
  @12       #14:GetLocal            | s@8:SetLocal[1] i@10:GetLocal[0] s@12:GetLocal[1]
  @14       #cb:I8Const             | s@8:SetLocal[1] i@10:GetLocal[0] s@12:GetLocal[1] i@14:I8Const
  @16   #e5 #1c:I32x4ExtractLane    | s@8:SetLocal[1] i@10:GetLocal[0] i@16:I32x4ExtractLane

R=ahaas@chromium.org, bbudge@chromium.org

Review-Url: https://codereview.chromium.org/2307733002
Cr-Commit-Position: refs/heads/master@{#39142}
      eed164b3
  13. 16 Jul, 2016 1 commit
  15. 15 Jul, 2016 2 commits
  17. 28 Jun, 2016 1 commit
  19. 23 Jun, 2016 1 commit
  21. 12 May, 2016 1 commit
    • ahaas's avatar
      [wasm] Implement parallel compilation. · 4aec7ba1
      ahaas authored 
      With this CL it is possible to compile a wasm module with multiple
threads in parallel. Parallel compilation works as follows:

1)   The main thread allocates a compilation unit for each wasm function.
2)   The main thread spawns WasmCompilationTasks which run on the
     background threads.
3.a) The background threads and the main thread pick one compilation unit
     at a time and execute the parallel phase of the compilation unit.
     After finishing the execution of the parallel phase, the compilation
     unit is stored in a result queue.
3.b) If the result queue contains a compilation unit, the main thread
     dequeues it and finishes its compilation.
4)   After the execution of the parallel phase of all compilation units has
     started, the main thread waits for all WasmCompilationTasks to finish.
5)   The main thread finalizes the compilation of the module.

I'm going to add some additional tests before committing this CL.

R=titzer@chromium.org, bmeurer@chromium.org, mlippautz@chromium.org, mstarzinger@chromium.org

Committed: https://crrev.com/17215438659d8ff2d7d55f95226bf8a1477ccd79
Cr-Commit-Position: refs/heads/master@{#36178}

Review-Url: https://codereview.chromium.org/1961973002
Cr-Commit-Position: refs/heads/master@{#36207}
      4aec7ba1
  23. 11 May, 2016 1 commit
  25. 03 May, 2016 1 commit
  27. 29 Apr, 2016 1 commit
    • titzer's avatar
      [wasm] Binary 11: WASM AST is now postorder. · 2aa4656e
      titzer authored 
      [wasm] Binary 11: br_table takes a value.
[wasm] Binary 11: Add implicit blocks to if arms.
[wasm] Binary 11: Add arities to call, return, and breaks
[wasm] Binary 11: Add experimental version.

This CL changes the encoder, decoder, and tests to use a postorder
encoding of the AST, which is more efficient in decode time and
space.

R=bradnelson@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=chromium:575167
LOG=Y

Review-Url: https://codereview.chromium.org/1830663002
Cr-Commit-Position: refs/heads/master@{#35896}
      2aa4656e
  29. 19 Apr, 2016 1 commit
  31. 03 Mar, 2016 2 commits
  33. 20 Jan, 2016 1 commit
  35. 17 Dec, 2015 1 commit
  37. 11 Dec, 2015 2 commits