PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=ahaas@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2666433002
Cr-Commit-Position: refs/heads/master@{#42793}
Committed: https://chromium.googlesource.com/v8/v8/+/544308b8f7351b55862d26ccc840fb210927f96a

[JaideepBajwa, 2017-01-29 16:36:36]

Description was changed from

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
==========

to

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
==========

[JaideepBajwa, 2017-01-29 16:36:36]

bjaideep@ca.ibm.com changed reviewers:
+ ahaas@chromium.org, titzer@chromium.org

[JaideepBajwa, 2017-01-29 16:37:06]

Description was changed from

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
==========

to

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=ahaas@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
BUG=
LOG=N
==========

[JaideepBajwa, 2017-01-29 16:37:32]

ptal

[john.yan, 2017-01-29 17:04:44]

lgtm

[JaideepBajwa, 2017-01-29 17:06:09]

The CQ bit was checked by bjaideep@ca.ibm.com to run a CQ dry run

[commit-bot: I haz the power, 2017-01-29 17:06:18]

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, 2017-01-29 17:44:15]

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

[commit-bot: I haz the power, 2017-01-29 17:44:16]

Dry run: This issue passed the CQ dry run.

[JaideepBajwa, 2017-01-30 19:45:19]

@titzer@chromium.org
@ahaas@chromium.org
ptal, need lgtm for wasm-compiler.cc.
Thank you.

[titzer, 2017-01-30 21:13:35]

On 2017/01/30 19:45:19, JaideepBajwa wrote:
> mailto:@titzer@chromium.org
> mailto:@ahaas@chromium.org
> ptal, need lgtm for wasm-compiler.cc.
> Thank you.

lgtm

[JaideepBajwa, 2017-01-30 21:15:49]

On 2017/01/30 21:13:35, titzer wrote:
> On 2017/01/30 19:45:19, JaideepBajwa wrote:
> > mailto:@titzer@chromium.org
> > mailto:@ahaas@chromium.org
> > ptal, need lgtm for wasm-compiler.cc.
> > Thank you.
> 
> lgtm

Thank you.

[JaideepBajwa, 2017-01-30 21:15:57]

The CQ bit was checked by bjaideep@ca.ibm.com

[commit-bot: I haz the power, 2017-01-30 21:16:00]

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-01-30 21:41:50]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1485810957637940,
"parent_rev": "735739bfa48628aa5a54a9874db35e0048511399", "commit_rev":
"544308b8f7351b55862d26ccc840fb210927f96a"}

[commit-bot: I haz the power, 2017-01-30 21:41:56]

Description was changed from

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=ahaas@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
BUG=
LOG=N
==========

to

==========
PPC/s390: [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm.

Port ca8d3ba7183d2b7a9691b2e732f7dbe8dc719a3e

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.

R=ahaas@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com,
michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2666433002
Cr-Commit-Position: refs/heads/master@{#42793}
Committed:
https://chromium.googlesource.com/v8/v8/+/544308b8f7351b55862d26ccc840fb21092...
==========

[commit-bot: I haz the power, 2017-01-30 21:41:57]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/v8/v8/+/544308b8f7351b55862d26ccc840fb21092...