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

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

  port f435d6222fa194c96c6be2e2d8a753016437931a(r41735)

  original commit message:
  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.

BUG=

Review-Url: https://codereview.chromium.org/2679853002
Cr-Commit-Position: refs/heads/master@{#42998}
Committed: https://chromium.googlesource.com/v8/v8/+/b240c4ffab2a2722aa0f15f4a92fde88c5738d60

[zhengxing.li, 2017-02-07 02:08:00]

zhengxing.li@intel.com changed reviewers:
+ ahaas@chromium.org, chunyang.dai@intel.com, titzer@chromium.org

[zhengxing.li, 2017-02-07 02:08:01]

PTAL, thanks!

[zhengxing.li, 2017-02-07 02:10:52]

On 2017/02/07 02:08:01, zhengxing.li wrote:
> PTAL, thanks!

Hi, titzer/ahaas:

  This CL adds V8_TARGET_ARCH_X87 in v8 common code
(src/compiler/wasm-compiler.cc), So need your LGTM to land it. thanks!

[ahaas, 2017-02-07 13:18:22]

On 2017/02/07 at 02:10:52, zhengxing.li wrote:
> On 2017/02/07 02:08:01, zhengxing.li wrote:
> > PTAL, thanks!
> 
> Hi, titzer/ahaas:
> 
>   This CL adds V8_TARGET_ARCH_X87 in v8 common code
(src/compiler/wasm-compiler.cc), So need your LGTM to land it. thanks!

lgtm

[Michael Starzinger, 2017-02-07 13:19:50]

mstarzinger@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Michael Starzinger, 2017-02-07 13:19:50]

LGTM (rubber-stamp of architecture-independent part, didn't look at the rest).

[zhengxing.li, 2017-02-07 14:18:29]

On 2017/02/07 13:19:50, Michael Starzinger wrote:
> LGTM (rubber-stamp of architecture-independent part, didn't look at the rest).

Thanks, ahaas/mstarzinger!

[zhengxing.li, 2017-02-07 14:18:39]

The CQ bit was checked by zhengxing.li@intel.com

[commit-bot: I haz the power, 2017-02-07 14:18:44]

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, 2017-02-07 14:40:59]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1486477119122280, "parent_rev":
"3df821c24efd956cee4c79bbe5cb8efda5f93d81", "commit_rev":
"b240c4ffab2a2722aa0f15f4a92fde88c5738d60"}

[commit-bot: I haz the power, 2017-02-07 14:41:02]

Description was changed from

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

  port f435d6222fa194c96c6be2e2d8a753016437931a(r41735)

  original commit message:
  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.

BUG=
==========

to

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

  port f435d6222fa194c96c6be2e2d8a753016437931a(r41735)

  original commit message:
  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.

BUG=

Review-Url: https://codereview.chromium.org/2679853002
Cr-Commit-Position: refs/heads/master@{#42998}
Committed:
https://chromium.googlesource.com/v8/v8/+/b240c4ffab2a2722aa0f15f4a92fde88c57...
==========

[commit-bot: I haz the power, 2017-02-07 14:41:03]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/v8/v8/+/b240c4ffab2a2722aa0f15f4a92fde88c57...