Fix arm64 deoptimization of double registers (reverts r20613).

Fix arm64 deoptimization from double registers (reverts r20613).

This reverts "ARM64: Use pair memory access in deoptimizer entry", r20613. It does not really make sense to micro-optimize the deoptimizer as it is the ultra-slow path. Moreover, the original code was easier to read (in addition to being correct).


BUG=391313
LOG=N
R=ulan@chromium.org

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

[Jarin, 2014-07-11 13:38:50]

Could you have a look?

[ulan, 2014-07-11 13:40:39]

lgtm

[m.m.capewell, 2014-07-11 14:35:19]

To clarify, this was an optimisation to reduce the size of the code generated
for deoptimization, not to improve performance.

[m.m.capewell, 2014-07-11 18:05:08]

I've looked into this a bit more, and find the problem in my code is that d15
isn't preserved, as it's not in the set of saved FP registers. The code that
this patch re-adds works because it preserves d15 by iterating through the saved
FP registers linearly, though due to this, it fails to preserve d28.

I've yet to discover why it's sensitive to d15, however, as that's a register
we've reserved for 0.0.

[Jarin, 2014-07-11 19:28:34]

On 2014/07/11 18:05:08, m.m.capewell wrote:
> I've looked into this a bit more, and find the problem in my code is that d15
> isn't preserved, as it's not in the set of saved FP registers. The code that
> this patch re-adds works because it preserves d15 by iterating through the
saved
> FP registers linearly, though due to this, it fails to preserve d28.
> 
> I've yet to discover why it's sensitive to d15, however, as that's a register
> we've reserved for 0.0.

We know what the root cause is - the original code correctly used allocation
index (e.g., allocation index of d20 is 19 - the zero register d15 is not
counted) for registers while the new unified code from r20613 uses the register
code. This means that data from registers d16-d31 are stored to a wrong place in
FrameDescription. It should be easy easy to fix - for double registers you
simply need to copy linearly rather than use the code() index. (Note that for
some bizarre reason the deoptimizer indexes normal registers differently from
double registers - normal registers use register code index, double registers
use allocation index, see the difference in Translation::StoreRegister and
Translation::StoreDoubleRegister in deoptimizer.cc.)

However, I am still thinking that this optimization is not worth the
complication in code - as far as I can see, this generated code always exists
only in one instance, so the memory saving should be small. Or am I missing
something?

[Jarin, 2014-07-11 19:30:59]

Committed patchset #1 manually as r22360 (presubmit successful).