[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

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}
Committed: https://chromium.googlesource.com/v8/v8/+/f435d6222fa194c96c6be2e2d8a753016437931a

[ahaas, 2016-12-13 15:49:33]

The CQ bit was checked by ahaas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-13 15:49:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-13 16:38:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-13 16:38:55]

Dry run: Try jobs failed on following builders:
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/19332)
  v8_win64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng_triggered/b...)

[ahaas, 2016-12-14 17:35:50]

The CQ bit was checked by ahaas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 17:35:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ahaas, 2016-12-14 17:41:32]

The CQ bit was checked by ahaas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 17:41:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 18:06:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-14 18:06:19]

Dry run: This issue passed the CQ dry run.

[ahaas, 2016-12-15 14:03:57]

The CQ bit was checked by ahaas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 14:04:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ahaas, 2016-12-15 14:04:54]

Description was changed from

==========
[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

R=titzer@chromium.org
==========

to

==========
[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

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
==========

[ahaas, 2016-12-15 14:05:48]

On 2016/12/13 at 15:49:32, ahaas wrote:
> 

I cleaned up the code in wasm-compiler.cc and wasm-opcodes.(h|cc).

[titzer, 2016-12-15 14:21:08]

lgtm if the header issue is resolved.

https://codereview.chromium.org/2571813002/diff/60001/src/wasm/wasm-opcodes.h
File src/wasm/wasm-opcodes.h (right):

https://codereview.chromium.org/2571813002/diff/60001/src/wasm/wasm-opcodes.h...
src/wasm/wasm-opcodes.h:10: #include "src/runtime/runtime.h"
I think it's best not to include the runtime header into the opcodes header for
WASM. This is only needed because the runtime header defines an enum. Is there
another place to put the helper function?

[commit-bot: I haz the power, 2016-12-15 14:30:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-15 14:30:33]

Dry run: This issue passed the CQ dry run.

[ahaas, 2016-12-15 16:55:08]

The CQ bit was checked by ahaas@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-15 16:55:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ahaas, 2016-12-15 16:55:51]

https://codereview.chromium.org/2571813002/diff/60001/src/wasm/wasm-opcodes.h
File src/wasm/wasm-opcodes.h (right):

https://codereview.chromium.org/2571813002/diff/60001/src/wasm/wasm-opcodes.h...
src/wasm/wasm-opcodes.h:10: #include "src/runtime/runtime.h"
On 2016/12/15 at 14:21:08, titzer wrote:
> I think it's best not to include the runtime header into the opcodes header
for WASM. This is only needed because the runtime header defines an enum. Is
there another place to put the helper function?

I moved the function to wasm-compiler.cc

[commit-bot: I haz the power, 2016-12-15 17:21:15]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-15 17:21:16]

Dry run: This issue passed the CQ dry run.

[ahaas, 2016-12-15 17:39:19]

The CQ bit was checked by ahaas@chromium.org

[ahaas, 2016-12-15 17:39:20]

The patchset sent to the CQ was uploaded after l-g-t-m from titzer@chromium.org
Link to the patchset: https://codereview.chromium.org/2571813002/#ps80001
(title: "Move TrapReasonToFunctionId from wasm-opcodes to wasm-compiler")

[commit-bot: I haz the power, 2016-12-15 17:39:27]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-15 17:41:04]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1481823559977960,
"parent_rev": "4f2cb8fe829ea84eb4920a7e3ec30bd9f3f5e7e6", "commit_rev":
"f435d6222fa194c96c6be2e2d8a753016437931a"}

[commit-bot: I haz the power, 2016-12-15 17:41:10]

Description was changed from

==========
[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

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
==========

to

==========
[wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32.

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}
Committed:
https://chromium.googlesource.com/v8/v8/+/f435d6222fa194c96c6be2e2d8a75301643...
==========

[commit-bot: I haz the power, 2016-12-15 17:41:11]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/v8/v8/+/f435d6222fa194c96c6be2e2d8a75301643...