ARM: Implement memcpy using NEON.

ARM: Implement memcpy using NEON.

Add support for a few NEON and ARM SIMD instructions and use them for various
memcpy operations.

BUG=none
TEST=none

Committed: https://code.google.com/p/v8/source/detail?r=15602

[ulan, 2013-06-28 15:07:42]

https://codereview.chromium.org/17858002/diff/14001/src/arm/codegen-arm.cc
File src/arm/codegen-arm.cc (right):

https://codereview.chromium.org/17858002/diff/14001/src/arm/codegen-arm.cc#ne...
src/arm/codegen-arm.cc:115: #if defined(V8_HOST_ARCH_ARM) && defined
(V8_HOST_CAN_READ_UNALIGNED)
It looks like V8_HOST_CAN_READ_UNALIGNED (which is set to 1 for armv7) doesn't
imply that the arch supports unaligned fp accesses.

I am getting "bus error" when running this cctest on Android devices:

cctest --nocrankshaft test-utils/MemMove --nobreak-on-abort
--nodead-code-elimination --nofold-constants

https://codereview.chromium.org/17858002/diff/14001/src/arm/disasm-arm.cc
File src/arm/disasm-arm.cc (right):

https://codereview.chromium.org/17858002/diff/14001/src/arm/disasm-arm.cc#new...
src/arm/disasm-arm.cc:446: ":%d", (1<<align)<<6);
Spaces around "<<".

https://codereview.chromium.org/17858002/diff/14001/src/platform.h
File src/platform.h (right):

https://codereview.chromium.org/17858002/diff/14001/src/platform.h#newcode380
src/platform.h:380: const uint8_t* src,
Indentation is off.

[Rodolph Perfetta, 2013-07-03 16:19:28]

ARMv7 CPU can perform unaligned accesses for ldr, ldrh but not ldrd and ldm.
There is no safe way to express this constraint in C so this part of the patch
have been reverted.

The memcpy routine will now detect neon/unaligned accesses at runtime.

[Rodolph Perfetta, 2013-07-03 16:59:38]

https://codereview.chromium.org/17858002/diff/14001/src/arm/disasm-arm.cc
File src/arm/disasm-arm.cc (right):

https://codereview.chromium.org/17858002/diff/14001/src/arm/disasm-arm.cc#new...
src/arm/disasm-arm.cc:446: ":%d", (1<<align)<<6);
On 2013/06/28 15:07:43, ulan wrote:
> Spaces around "<<".

Done.

https://codereview.chromium.org/17858002/diff/14001/src/platform.h
File src/platform.h (right):

https://codereview.chromium.org/17858002/diff/14001/src/platform.h#newcode380
src/platform.h:380: const uint8_t* src,
On 2013/06/28 15:07:43, ulan wrote:
> Indentation is off.

Done.

[ulan, 2013-07-09 15:16:32]

LGTM with nits.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
File src/arm/assembler-arm.cc (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
src/arm/assembler-arm.cc:398: switch (align) {
Extracting this switch into a function would avoid code duplication below.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
src/arm/assembler-arm.cc:1832: void Assembler::pld(const MemOperand& address) {
Missing the description comment.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
File src/arm/codegen-arm.cc (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
src/arm/codegen-arm.cc:137: Label loop, less_256, less_128, less_64, less_32,
_16_or_less, _8_or_less;
The main loop copies 64 byte at a time. Why don't we prefetch 64 bytes? Or does
prefetching by more make big performance difference?

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
src/arm/codegen-arm.cc:173: __ pld(MemOperand(src, 256));
Shouldn't this be __ pld(MemOperand(src, 256 - 32)) since src advanced by 64?

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/v8utils.h
File src/v8utils.h (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/v8utils.h#newc...
src/v8utils.h:431: memcpy(dest, src, 15);
OK, if this gives perf. improvement compared to memcpy(dest, src, chars).

[vincent.belliard.fr, 2013-07-10 15:30:37]

https://chromiumcodereview.appspot.com/17858002/diff/14001/src/arm/disasm-arm.cc
File src/arm/disasm-arm.cc (right):

https://chromiumcodereview.appspot.com/17858002/diff/14001/src/arm/disasm-arm...
src/arm/disasm-arm.cc:446: ":%d", (1<<align)<<6);
On 2013/06/28 15:07:43, ulan wrote:
> Spaces around "<<".

Done.

https://chromiumcodereview.appspot.com/17858002/diff/14001/src/platform.h
File src/platform.h (right):

https://chromiumcodereview.appspot.com/17858002/diff/14001/src/platform.h#new...
src/platform.h:380: const uint8_t* src,
On 2013/06/28 15:07:43, ulan wrote:
> Indentation is off.

Done.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
File src/arm/assembler-arm.cc (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
src/arm/assembler-arm.cc:398: switch (align) {
On 2013/07/09 15:16:32, ulan wrote:
> Extracting this switch into a function would avoid code duplication below.

Done.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/assembler-...
src/arm/assembler-arm.cc:1832: void Assembler::pld(const MemOperand& address) {
On 2013/07/09 15:16:32, ulan wrote:
> Missing the description comment.

Done.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
File src/arm/codegen-arm.cc (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
src/arm/codegen-arm.cc:137: Label loop, less_256, less_128, less_64, less_32,
_16_or_less, _8_or_less;
With ARM, pld starts a load but doesn't wait for the result. If we only preload
64 bytes, it wouldn't speedup anything because we would do the load just after
the preload (in fact in would add a little overhead). We need a preload of 256
to have the best result.
However, loading too much data would slowdown. That why we try to preload
exactly what we need (we only preload up to 63 extra bytes).

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/arm/codegen-ar...
src/arm/codegen-arm.cc:173: __ pld(MemOperand(src, 256));
On 2013/07/09 15:16:32, ulan wrote:
> Shouldn't this be __ pld(MemOperand(src, 256 - 32)) since src advanced by 64?

Done.

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/v8utils.h
File src/v8utils.h (right):

https://chromiumcodereview.appspot.com/17858002/diff/25001/src/v8utils.h#newc...
src/v8utils.h:431: memcpy(dest, src, 15);
This gives good improvement. For small known sizes, gcc generates the good
instructions (ldrb, ldrh, ldr) to copy the needed size.