Implement WASM big-endian support

Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data
in memory in little-endian order, and changing data
endianness before storing to memory and after loading from
memory.

BUG=

Committed: https://crrev.com/d3f3f6c8186b2a53f0c539f7bba0c3708c4d83f9
Cr-Commit-Position: refs/heads/master@{#37065}

[ivica.bogosavljevic, 2016-06-03 14:13:08]

Description was changed from

==========
Implement WASM big-endian support

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

to

==========
Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data 
in memory in little-endian order, and changing data 
endianness before storing to memory and after loading from
memory.

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

[ivica.bogosavljevic, 2016-06-03 14:13:09]

ivica.bogosavljevic@imgtec.com changed reviewers:
+ akos.palfi@imgtec.com, balazs.kilvady@imgtec.com, titzer@chromium.org

[ivica.bogosavljevic, 2016-06-03 14:14:52]

PTAL

This fixes all failures in cctest related to wasm on MIPS64: test-run-wasm/*,
test-run-wasm-64/*, test-run-wasm-asmjs/* and test-run-wasm-js/*

There are some failures related to MIPS32 and doubles because of int64-lowering,
this will be fixed in next iterations

[titzer, 2016-06-06 07:44:00]

Looks mostly good.

https://codereview.chromium.org/2034093002/diff/20001/src/compiler/wasm-compi...
File src/compiler/wasm-compiler.cc (right):

https://codereview.chromium.org/2034093002/diff/20001/src/compiler/wasm-compi...
src/compiler/wasm-compiler.cc:1046: Binop(shiftLeftOpcode, value,
jsgraph()->Int32Constant(shiftCount));
Reusing the Binop() routine is a little inefficient, since it goes through
another switch and also the logic to mask shift counts if necessary. Can you
build the shift node directly here?

https://codereview.chromium.org/2034093002/diff/20001/src/compiler/wasm-compi...
src/compiler/wasm-compiler.cc:1094: Diamond d(graph(), jsgraph()->common(),
Unop(wasm::kExprI32Eqz, signBit));
What about using (x << machine_width - width) >> (machine_width - width)?

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h
File src/utils.h (right):

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1552
src/utils.h:1552: static inline V ReadLittleEndianValue(const void* p) {
Is it possible to unify these routines with those in wasm/decoder.h and
wasm/encoder.h?

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1558
src/utils.h:1558: byte* dst = reinterpret_cast<byte*>(&ret);
That kind of type punning is undefined behavior in C++, so it will unfortunately
break one day. A memmove will work.

https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
File src/wasm/wasm-interpreter.cc (right):

https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
src/wasm/wasm-interpreter.cc:1450: WasmVal
result(static_cast<ctype>(ReadLittleEndianValue<mtype>(addr))); \
I think you can use the routines in decoder.h for these.

https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
File test/cctest/wasm/wasm-run-utils.h (right):

https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
test/cctest/wasm/wasm-run-utils.h:159: void WriteMemory(T* p, T val) {
Can we unify these routines with the others?

[john.yan, 2016-06-07 17:46:59]

jyan@ca.ibm.com changed reviewers:
+ jyan@ca.ibm.com

[john.yan, 2016-06-07 17:47:00]

https://codereview.chromium.org/2034093002/diff/20001/src/compiler/wasm-compi...
File src/compiler/wasm-compiler.cc (right):

https://codereview.chromium.org/2034093002/diff/20001/src/compiler/wasm-compi...
src/compiler/wasm-compiler.cc:2883: // TODO(mips-team) Implement byte swap
turbofan operator
FYI: https://codereview.chromium.org/2045943002/

[john.yan, 2016-06-09 18:21:50]

On 2016/06/03 14:14:52, ivica.bogosavljevic wrote:
> PTAL
> 
> This fixes all failures in cctest related to wasm on MIPS64: test-run-wasm/*,
> test-run-wasm-64/*, test-run-wasm-asmjs/* and test-run-wasm-js/*
> 
> There are some failures related to MIPS32 and doubles because of
int64-lowering,
> this will be fixed in next iterations

Hello Ivica, do you have any updates on this one?

Thanks.

[ivica.bogosavljevic, 2016-06-10 14:08:29]

On 2016/06/09 18:21:50, john.yan wrote:
> On 2016/06/03 14:14:52, ivica.bogosavljevic wrote:
> > PTAL
> > 
> > This fixes all failures in cctest related to wasm on MIPS64:
test-run-wasm/*,
> > test-run-wasm-64/*, test-run-wasm-asmjs/* and test-run-wasm-js/*
> > 
> > There are some failures related to MIPS32 and doubles because of
> int64-lowering,
> > this will be fixed in next iterations
> 
> Hello Ivica, do you have any updates on this one?
> 
> Thanks.

I have been busy with other tasks. Just to make clear, do you want me to land 
this change first, and then you will rebase your changes on top of it?

[john.yan, 2016-06-10 14:58:32]

On 2016/06/10 14:08:29, ivica.bogosavljevic wrote:
> On 2016/06/09 18:21:50, john.yan wrote:
> > On 2016/06/03 14:14:52, ivica.bogosavljevic wrote:
> > > PTAL
> > > 
> > > This fixes all failures in cctest related to wasm on MIPS64:
> test-run-wasm/*,
> > > test-run-wasm-64/*, test-run-wasm-asmjs/* and test-run-wasm-js/*
> > > 
> > > There are some failures related to MIPS32 and doubles because of
> > int64-lowering,
> > > this will be fixed in next iterations
> > 
> > Hello Ivica, do you have any updates on this one?
> > 
> > Thanks.
> 
> I have been busy with other tasks. Just to make clear, do you want me to land 
> this change first, and then you will rebase your changes on top of it?

Yes, please.

[ivica.bogosavljevic, 2016-06-13 14:59:03]

PTAL

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h
File src/utils.h (right):

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1552
src/utils.h:1552: static inline V ReadLittleEndianValue(const void* p) {
On 2016/06/06 07:44:00, titzer wrote:
> Is it possible to unify these routines with those in wasm/decoder.h and
> wasm/encoder.h?

I suggest we keep ReadLittleEndianValue and WriteLittleEndianValue, and modify
read_ and write methods in encoder.h and decoder.h to use  them.

https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1558
src/utils.h:1558: byte* dst = reinterpret_cast<byte*>(&ret);
On 2016/06/06 07:44:00, titzer wrote:
> That kind of type punning is undefined behavior in C++, so it will
unfortunately
> break one day. A memmove will work.

For big-endian implementation, we need to swap bytes within word. memmove
doesn't do this. We could implement the same using byte reading and shifting,
but this doesn't works for floats. At the end, we need to convert the void *
pointer to byte * pointer, I don't see any other way to do this so it works with
both integers and floats

https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
File src/wasm/wasm-interpreter.cc (right):

https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
src/wasm/wasm-interpreter.cc:1450: WasmVal
result(static_cast<ctype>(ReadLittleEndianValue<mtype>(addr))); \
On 2016/06/06 07:44:00, titzer wrote:
> I think you can use the routines in decoder.h for these.

I would like to leave this method as it is, because STORE_CASE cannot use
decoder.write_value in the same way LOAD_CASE can use decoder.read_value (we
would need to add new methods to decoder.h, but these methods already exists
elsewhere)

https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
File test/cctest/wasm/wasm-run-utils.h (right):

https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
test/cctest/wasm/wasm-run-utils.h:159: void WriteMemory(T* p, T val) {
On 2016/06/06 07:44:00, titzer wrote:
> Can we unify these routines with the others?

We could use ReadLittleEndianValue and WriteLittleEndianValue, but please see
other comments first.

https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
test/cctest/wasm/wasm-run-utils.h:170: #endif
For myself: Commented code, needs to be removed

[john.yan, 2016-06-14 01:12:20]

On 2016/06/13 14:59:03, ivica.bogosavljevic wrote:
> PTAL
> 
> https://codereview.chromium.org/2034093002/diff/20001/src/utils.h
> File src/utils.h (right):
> 
> https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1552
> src/utils.h:1552: static inline V ReadLittleEndianValue(const void* p) {
> On 2016/06/06 07:44:00, titzer wrote:
> > Is it possible to unify these routines with those in wasm/decoder.h and
> > wasm/encoder.h?
> 
> I suggest we keep ReadLittleEndianValue and WriteLittleEndianValue, and modify
> read_ and write methods in encoder.h and decoder.h to use  them.
> 
> https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1558
> src/utils.h:1558: byte* dst = reinterpret_cast<byte*>(&ret);
> On 2016/06/06 07:44:00, titzer wrote:
> > That kind of type punning is undefined behavior in C++, so it will
> unfortunately
> > break one day. A memmove will work.
> 
> For big-endian implementation, we need to swap bytes within word. memmove
> doesn't do this. We could implement the same using byte reading and shifting,
> but this doesn't works for floats. At the end, we need to convert the void *
> pointer to byte * pointer, I don't see any other way to do this so it works
with
> both integers and floats
> 
>
https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
> File src/wasm/wasm-interpreter.cc (right):
> 
>
https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
> src/wasm/wasm-interpreter.cc:1450: WasmVal
> result(static_cast<ctype>(ReadLittleEndianValue<mtype>(addr))); \
> On 2016/06/06 07:44:00, titzer wrote:
> > I think you can use the routines in decoder.h for these.
> 
> I would like to leave this method as it is, because STORE_CASE cannot use
> decoder.write_value in the same way LOAD_CASE can use decoder.read_value (we
> would need to add new methods to decoder.h, but these methods already exists
> elsewhere)
> 
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> File test/cctest/wasm/wasm-run-utils.h (right):
> 
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> test/cctest/wasm/wasm-run-utils.h:159: void WriteMemory(T* p, T val) {
> On 2016/06/06 07:44:00, titzer wrote:
> > Can we unify these routines with the others?
> 
> We could use ReadLittleEndianValue and WriteLittleEndianValue, but please see
> other comments first.
> 
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> test/cctest/wasm/wasm-run-utils.h:170: #endif
> For myself: Commented code, needs to be removed

lgtm!

[titzer, 2016-06-16 22:45:15]

On 2016/06/14 01:12:20, john.yan wrote:
> On 2016/06/13 14:59:03, ivica.bogosavljevic wrote:
> > PTAL
> > 
> > https://codereview.chromium.org/2034093002/diff/20001/src/utils.h
> > File src/utils.h (right):
> > 
> >
https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1552
> > src/utils.h:1552: static inline V ReadLittleEndianValue(const void* p) {
> > On 2016/06/06 07:44:00, titzer wrote:
> > > Is it possible to unify these routines with those in wasm/decoder.h and
> > > wasm/encoder.h?
> > 
> > I suggest we keep ReadLittleEndianValue and WriteLittleEndianValue, and
modify
> > read_ and write methods in encoder.h and decoder.h to use  them.
> > 
> >
https://codereview.chromium.org/2034093002/diff/20001/src/utils.h#newcode1558
> > src/utils.h:1558: byte* dst = reinterpret_cast<byte*>(&ret);
> > On 2016/06/06 07:44:00, titzer wrote:
> > > That kind of type punning is undefined behavior in C++, so it will
> > unfortunately
> > > break one day. A memmove will work.
> > 
> > For big-endian implementation, we need to swap bytes within word. memmove
> > doesn't do this. We could implement the same using byte reading and
shifting,
> > but this doesn't works for floats. At the end, we need to convert the void *
> > pointer to byte * pointer, I don't see any other way to do this so it works
> with
> > both integers and floats
> > 
> >
>
https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
> > File src/wasm/wasm-interpreter.cc (right):
> > 
> >
>
https://codereview.chromium.org/2034093002/diff/20001/src/wasm/wasm-interpret...
> > src/wasm/wasm-interpreter.cc:1450: WasmVal
> > result(static_cast<ctype>(ReadLittleEndianValue<mtype>(addr))); \
> > On 2016/06/06 07:44:00, titzer wrote:
> > > I think you can use the routines in decoder.h for these.
> > 
> > I would like to leave this method as it is, because STORE_CASE cannot use
> > decoder.write_value in the same way LOAD_CASE can use decoder.read_value (we
> > would need to add new methods to decoder.h, but these methods already exists
> > elsewhere)
> > 
> >
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> > File test/cctest/wasm/wasm-run-utils.h (right):
> > 
> >
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> > test/cctest/wasm/wasm-run-utils.h:159: void WriteMemory(T* p, T val) {
> > On 2016/06/06 07:44:00, titzer wrote:
> > > Can we unify these routines with the others?
> > 
> > We could use ReadLittleEndianValue and WriteLittleEndianValue, but please
see
> > other comments first.
> > 
> >
>
https://codereview.chromium.org/2034093002/diff/20001/test/cctest/wasm/wasm-r...
> > test/cctest/wasm/wasm-run-utils.h:170: #endif
> > For myself: Commented code, needs to be removed
> 
> lgtm!

lgtm.

Sorry for the delay, I have been traveling.

[ivica.bogosavljevic, 2016-06-17 08:00:16]

The CQ bit was checked by ivica.bogosavljevic@imgtec.com to run a CQ dry run

[commit-bot: I haz the power, 2016-06-17 08:00:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2034093002/60001

[commit-bot: I haz the power, 2016-06-17 08:01:30]

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

[commit-bot: I haz the power, 2016-06-17 08:01:32]

Dry run: Try jobs failed on following builders:
  v8_linux64_asan_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel_ng/buil...)
  v8_linux64_avx2_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/7475)
  v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
  v8_linux_nodcheck_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...)
  v8_linux_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/7434)
  v8_mac_rel_ng on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng/builds/3373)
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/17440)

[ivica.bogosavljevic, 2016-06-17 11:13:27]

The CQ bit was checked by ivica.bogosavljevic@imgtec.com to run a CQ dry run

[commit-bot: I haz the power, 2016-06-17 11:13:29]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2034093002/80001

[commit-bot: I haz the power, 2016-06-17 11:44:10]

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

[commit-bot: I haz the power, 2016-06-17 11:44:12]

Dry run: This issue passed the CQ dry run.

[ivica.bogosavljevic, 2016-06-17 11:49:16]

The CQ bit was checked by ivica.bogosavljevic@imgtec.com

[ivica.bogosavljevic, 2016-06-17 11:49:17]

The patchset sent to the CQ was uploaded after l-g-t-m from titzer@chromium.org,
jyan@ca.ibm.com
Link to the patchset: https://codereview.chromium.org/2034093002/#ps80001
(title: "Small fixes. Rebase to master")

[commit-bot: I haz the power, 2016-06-17 11:49:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2034093002/80001

[commit-bot: I haz the power, 2016-06-17 11:51:22]

Description was changed from

==========
Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data 
in memory in little-endian order, and changing data 
endianness before storing to memory and after loading from
memory.

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

to

==========
Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data 
in memory in little-endian order, and changing data 
endianness before storing to memory and after loading from
memory.

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

[commit-bot: I haz the power, 2016-06-17 11:51:23]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-06-17 11:53:33]

Description was changed from

==========
Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data 
in memory in little-endian order, and changing data 
endianness before storing to memory and after loading from
memory.

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

to

==========
Implement WASM big-endian support.

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data
in memory in little-endian order, and changing data
endianness before storing to memory and after loading from
memory.

BUG=

Committed: https://crrev.com/d3f3f6c8186b2a53f0c539f7bba0c3708c4d83f9
Cr-Commit-Position: refs/heads/master@{#37065}
==========

[commit-bot: I haz the power, 2016-06-17 11:53:35]

Patchset 5 (id:??) landed as
https://crrev.com/d3f3f6c8186b2a53f0c539f7bba0c3708c4d83f9
Cr-Commit-Position: refs/heads/master@{#37065}

[Michael Achenbach, 2016-06-20 07:08:28]

A revert of this CL (patchset #5 id:80001) has been created in
https://codereview.chromium.org/2080153002/ by machenbach@chromium.org.

The reason for reverting is: [Sheriff] Speculative revert for crashes on
chrubuntu chromebooks:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm/builds/320.