ARM64: Give LR to the allocator.

ARM64: Give LR to the allocator.

By avoiding the 'Call' mechanism for entering the deopt handler, we can
give LR to the register allocator, to treat like any other caller-saved
register. This makes the entry mechanism a little more complicated since
the caller address needs to be constructed manually using adr, but only
in the slow (deopt) path.

BUG=

[ulan, 2014-06-20 10:56:39]

Do you have performance numbers for this?

[jbramley, 2014-06-23 08:34:00]

On 2014/06/20 10:56:39, ulan wrote:
> Do you have performance numbers for this?

It doesn't make any measurable difference to Octane or Kraken, I'm afraid. It's
really just a clean-up, since it avoids having a special-purpose register. It
might provide some benefit if we're able to improve the register allocator in
some way later.

[ulan, 2014-06-23 11:17:11]

Probably ARM would benefit more from extra register. If you plan to implement
the same for ARM then we can land this.

https://codereview.chromium.org/341863002/diff/1/src/arm64/deoptimizer-arm64.cc
File src/arm64/deoptimizer-arm64.cc (right):

https://codereview.chromium.org/341863002/diff/1/src/arm64/deoptimizer-arm64....
src/arm64/deoptimizer-arm64.cc:53: patcher.blr(ip0);
Did you mean br(ip0) here?

https://codereview.chromium.org/341863002/diff/1/src/arm64/lithium-codegen-ar...
File src/arm64/lithium-codegen-arm64.cc (right):

https://codereview.chromium.org/341863002/diff/1/src/arm64/lithium-codegen-ar...
src/arm64/lithium-codegen-arm64.cc:845: Register entry_offset =
temps.Acquire(ip1);
Nit: maybe introduce a descriptive alias for ip1 to make places that set it and
use it easier to find?

[jbramley, 2014-06-23 17:22:05]

> Probably ARM would benefit more from extra register. If you plan to implement
> the same for ARM then we can land this.

Yes, ARM ought to benefit much more. I'm not as familiar with the ARM back-end
in V8, but I believe there are spare registers that we could use. Would you like
me to prepare the ARM patch before finishing this one?

https://codereview.chromium.org/341863002/diff/1/src/arm64/deoptimizer-arm64.cc
File src/arm64/deoptimizer-arm64.cc (right):

https://codereview.chromium.org/341863002/diff/1/src/arm64/deoptimizer-arm64....
src/arm64/deoptimizer-arm64.cc:53: patcher.blr(ip0);
On 2014/06/23 11:17:11, ulan wrote:
> Did you mean br(ip0) here?

Yes! Thank you.

https://codereview.chromium.org/341863002/diff/1/src/arm64/lithium-codegen-ar...
File src/arm64/lithium-codegen-arm64.cc (right):

https://codereview.chromium.org/341863002/diff/1/src/arm64/lithium-codegen-ar...
src/arm64/lithium-codegen-arm64.cc:845: Register entry_offset =
temps.Acquire(ip1);
On 2014/06/23 11:17:11, ulan wrote:
> Nit: maybe introduce a descriptive alias for ip1 to make places that set it
and
> use it easier to find?

Done.

[ulan, 2014-06-27 13:17:48]

lgtm

> Would you like me to prepare the ARM patch before finishing this one?
Feel free to land this before starting the ARM patch.

[jbramley, 2015-03-13 14:56:10]

On 2014/06/27 13:17:48, ulan wrote:
> lgtm
> 
> > Would you like me to prepare the ARM patch before finishing this one?
> Feel free to land this before starting the ARM patch.

By the way, whilst working on the ARM patch I found some problems common to
ARM64, we just don't see them with ARM64 because there isn't enough register
pressure for LR to be allocated in the troublesome cases.

I'll discard this review, and possibly resurrect it later if I find a sensible
way to free up LR. You're right, though, ARM32 is the priority because it would
benefit more from the extra register.