ARM, ARM64: Optimize array copy

ARM, ARM64: Optimize array copy

R=ulan@chromium.org, bmeurer@chromium.org

BUG=

[vincent.belliard, 2014-06-12 14:06:55]

The purpose of the patch is to speedup arrays copy.

We did that with two new hydrogen instructions (FillElementsWithHole and
CopyElements).

These two instructions are only implemented for ARM and ARM64. Therefor, we have
some ifdef in hydrogen.cc (but they they would be removed if these two
instructions are implemented for all the platforms).

Benchmarks a little bit faster:
A15: Kraken 0.9% faster, Octane2 0.5% better
A53: Kraken 0.74% faster, Octane2 0.4% better
A57: Kraken 0.14% faster, Octane2 0.6% better
And:
A57: octane2/gameboy 2% better kraken/aes 3.9% faster kraken/pbkdf2 3.6% faster
kraken/ccm 3.1% faster kraken/oscillator 2.3% faster
A15: octane2/gameboy 1.5% better kraken/fft 3.1% faster kraken/pbkdf2 1.9%
faster kraken/financial 1.7% faster kraken/sha256 1.7% faster

[ulan, 2014-06-20 11:57:23]

I don't have better way to implement this optimization, but adding new hydrogen
instructions for copying does not look good to me. It introduces a lot of
platform-specific code, which we would like to minimize.

[Jakob Kummerow, 2014-06-20 12:37:47]

On Fri, Jun 20, 2014 at 2:20 PM, Vincent Belliard
<vincent.belliard.arm@gmail.com> wrote:
> I don't see an other way to do it either.
> I understand your aim to reduce platform specific code 
> (even if memcopy and memset are quite basic functions).
> Shall I close this CL?

I agree that adding this much Lithium code is undesirable. Two thoughts:
(1) Why exactly is the hand-written code faster, what extra work does it avoid?
What would it take to improve Hydrogen to generate code that's just as good?
(2) I don't see any write barriers in the new code. If the reason it's faster is
because you're skipping those, then that's a big no-no anyway and not worth
pursuing further.

[vincent.belliard, 2014-06-23 07:57:30]

The code is faster because it first compute the base addresses and then uses
post index accesses. For ARM 64, it also copy two values in one instruction.
Also, the hole nan (double value) used to initialize the array is loaded once
before the loop and not inside the loop.

To be able to do that within hydrogen, we would need untagged pointer (a priori
only valid if the code can't deopt or allocate) and a pointer access with post
increment.

There is no write barriers in the code because, recently, you push a CL which
always allocate the arrays in the new generation. Before that CL, I had a
version with write barriers which gave the same results.