Speed up A64 simulator by removing useless memcpy.

Speed up A64 simulator by removing useless memcpy.

The addresses involved should always be aligned, so we can simply use
a cast, just like the ARM simulator. Even if the alignment assumption
did not hold and the platform we are running on couldn't handle
unaligned access, some #ifdefs would be much more preferable. The
affected member functions were the top 2 in a profile (18% and 15%),
so basically every hack is allowed here to speed things up. :-)

Removed some dead code for literals on the way. If we need to
resurrect it, we should do it without double(!) memcpys.

Generally, I still don't understand why we need the Instr/Instruction
distinction or simply wrap Instr within Instruction, this seems to
be much simpler and cleaner, but this would involve heavier changes.

The overall speedup of this CL is roughly 37%, see the numbers below
for a reduced Octane suite and the check targets:

------------------------------------------------------------
With memcpy:
------------------------------------------------------------

make -j32 a64.release.quickcheck => 03:29
make -j32 a64.release.check      => 11:30
Reduced Octane suite             => 05:16
Richards: 35.1
DeltaBlue: 64.1
RayTrace: 130
Splay: 66.1
SplayLatency: 619
NavierStokes: 58.7
PdfJS: 89.6
Mandreel: 58.5
MandreelLatency: 242
CodeLoad: 5103
Box2D: 124
----
Score (version 9): 144

------------------------------------------------------------
With casts:
------------------------------------------------------------
make -j32 a64.release.quickcheck => 02:14
make -j32 a64.release.check      => 07:21
Reduced Octane suite             => 03:21
Richards: 53.3
DeltaBlue: 103
RayTrace: 205
Splay: 95.9
SplayLatency: 859
NavierStokes: 103
PdfJS: 136
Mandreel: 94.8
MandreelLatency: 386
CodeLoad: 6493
Box2D: 179
----
Score (version 9): 219

R=ulan@chromium.org

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

[Sven Panne, 2014-03-13 12:31:56]

Ulan just pointed me to https://codereview.chromium.org/169223004/, which is a
subset of this CL. I think that the discussion about pointer aliasing is right
in theory, but very wrong in practice: We do *exactly* the same casts in the ARM
emulator for years, without any problems. Furthermore, we have *tons* of casts
in v8 which are wrong under strict aliasing rules. (You can talk to Mads about
this, he was very passionate about this ;-)

If there are no other (mostly theoretical) objections, I very much like to land
this, because it saves a tremendous amount of developer/bot time with a tiny
change.

The *right* way of doing this is either throwing away the useless distinction
between Instr and Instruction or make Instruction carry an Instr as a member
field, but this would probably be a bigger change. If somebody has time left it
can be done, but in the meantime let's speed up our daily work.

[Sven Panne, 2014-03-14 10:24:21]

After the recent offline/email discussion, I think the conclusion was to land
this and remove the need for all those casts step-by-step, so I need an LGTM.
:-)

[ulan, 2014-03-14 10:33:06]

> After the recent offline/email discussion, I think the conclusion was to land
> this and remove the need for all those casts step-by-step, so I need an LGTM.
> :-)
I don't have strong opinion on this. Since it is fine with Rodolph and Jacob, it
lgtm.

[Sven Panne, 2014-03-14 10:34:53]

On 2014/03/14 10:33:06, ulan wrote:
> I don't have strong opinion on this. Since it is fine with Rodolph and Jacob,
it
> lgtm.

OK, I'll land it then. Just for reference:

https://github.com/armvixl/vixl/blob/f37fdc0b307fc66239b8b754b0465d36bc0f8aed...
https://github.com/armvixl/vixl/blob/f37fdc0b307fc66239b8b754b0465d36bc0f8aed...

;-) :-D

[Sven Panne, 2014-03-14 10:36:19]

Committed patchset #4 manually as r19929 (presubmit successful).