[arm64] Use SP-offset rather than FP-offset.

[arm64] Use SP-offset rather than FP-offset.

A64 loads and stores can have much larger positive than negative
immediate offsets, and since most frame slots are below fp, we can
significantly improve accesses by basing them on sp instead. Typical
example:

    Before                  After
    mov x16, #-416
    str x20, [fp, x16]      str x20, [jssp, #32]

Notable benchmark results include lua_binarytrees, which improves by
about 7.5% on A57 and 5% on A53. Several other asm.js benchmarks gain
2-4%.

Committed: https://crrev.com/dad635ee7ada527cf9d5a0c4317ae1a226876a38
Cr-Commit-Position: refs/heads/master@{#32111}

[jbramley, 2015-09-30 10:51:52]

jacob.bramley@arm.com changed reviewers:
+ bmeurer@chromium.org, dcarney@chromium.org, ulan@chromium.org

[Benedikt Meurer, 2015-09-30 14:11:25]

bmeurer@chromium.org changed reviewers:
+ danno@chromium.org, titzer@chromium.org
- dcarney@chromium.org

[Benedikt Meurer, 2015-09-30 14:11:26]

I like the idea, but I'm not sure about the approach, esp. interplay with frame
elision. Adding Danno and Ben for more opinions on this.

[titzer, 2015-09-30 14:14:48]

On 2015/09/30 14:11:26, Benedikt Meurer wrote:
> I like the idea, but I'm not sure about the approach, esp. interplay with
frame
> elision. Adding Danno and Ben for more opinions on this.

I like this idea too, since we can support native calling conventions more
easily (which basically don't work on arm64). This also means that we don't need
the FP for anything, since we should be able to calculate the offset from SP for
incoming arguments, the return address, etc.

[jbramley, 2015-09-30 14:25:04]

On 2015/09/30 14:11:26, Benedikt Meurer wrote:
> I like the idea, but I'm not sure about the approach, esp. interplay with
frame
> elision. Adding Danno and Ben for more opinions on this.

It doesn't touch frame elision as far as I am aware. (I renamed some variables
in `Frame` but didn't change the behaviour.)

Note that we still use the stack in the same way before and after this patch.
All I really did was make the `Frame` class aware of our transient stack usage
so I can accurately determine the sp-to-fp offset.

[danno, 2015-10-05 13:48:27]

On 2015/09/30 at 14:25:04, jacob.bramley wrote:
> On 2015/09/30 14:11:26, Benedikt Meurer wrote:
> > I like the idea, but I'm not sure about the approach, esp. interplay with
frame
> > elision. Adding Danno and Ben for more opinions on this.
> 
> It doesn't touch frame elision as far as I am aware. (I renamed some variables
in `Frame` but didn't change the behaviour.)
> 
> Note that we still use the stack in the same way before and after this patch.
All I really did was make the `Frame` class aware of our transient stack usage
so I can accurately determine the sp-to-fp offset.

I haven't forgotten about this. I looked over this today and generally it seems
like a sound approach. However, we need a mechanism like this on all platforms
for TailCalls, and I would like to make it a little more robust and amenable to
getting right cross-platform. I need to think a little about how that might be
possible. Some sort of x-platform bottleneck for all of the parameter pushing,
calls, etc. seems like it would help, but I am not quite sure how to bridge the
impedance mismatch between "Claim" on arm64 and Push on other platforms.

[danno, 2015-11-05 21:40:45]

After discussing with Benedikt and thinking about this for a while, I think your
current approach is about as good it can get without adding a bunch of
heavy-handed abstraction layers on top of TF parameter passing, and that
abstraction would be awfully baroque for the limited value it would provide.

I'm also not immediately worried about interactions with frame elision. Although
there certainly will be interplay, my suspicion is that most of the logic in
this CL will work out of the box if the other non-stack parameter areas of the
frame are just kept empty in the frame elision case.

I wondered if you might be willing to do the platform ports of this, but then
realize that without frame elision, there is currently no good way to test this
on them. So LGTM.

[jbramley, 2015-11-06 09:15:18]

On 2015/11/05 21:40:45, danno wrote:
> After discussing with Benedikt and thinking about this for a while, I think
your
> current approach is about as good it can get without adding a bunch of
> heavy-handed abstraction layers on top of TF parameter passing, and that
> abstraction would be awfully baroque for the limited value it would provide.
> 
> I'm also not immediately worried about interactions with frame elision.
Although
> there certainly will be interplay, my suspicion is that most of the logic in
> this CL will work out of the box if the other non-stack parameter areas of the
> frame are just kept empty in the frame elision case.

Hopefully, yes. I'm not really too sure about how frame elision is going to
work.

> I wondered if you might be willing to do the platform ports of this, but then
> realize that without frame elision, there is currently no good way to test
this
> on them. So LGTM.

Ok, thanks!

I did port it to ARM, if only to see if that threw in any surprises, but it has
no effect there whatsoever. I can tweak the selection logic to make it fire (and
test correctness) but under normal conditions the frames just don't get big
enough in any of our benchmarks.

[jbramley, 2015-11-06 10:48:16]

The CQ bit was checked by jacob.bramley@arm.com

[jbramley, 2015-11-06 10:48:16]

The patchset sent to the CQ was uploaded after l-g-t-m from danno@chromium.org
Link to the patchset: https://codereview.chromium.org/1376173003/#ps20001
(title: "Rebase.")

[commit-bot: I haz the power, 2015-11-06 10:48:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1376173003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1376173003/20001

[commit-bot: I haz the power, 2015-11-06 10:50:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-11-06 10:50:51]

Try jobs failed on following builders:
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/7513)

[jbramley, 2015-11-06 11:09:33]

On 2015/11/06 10:50:51, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   v8_presubmit on tryserver.v8 (JOB_FAILED,
> http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/7513)

Presubmit seems to want another review. Any takers?

[Benedikt Meurer, 2015-11-19 10:27:16]

lgtm

[jbramley, 2015-11-19 11:24:59]

The CQ bit was checked by jacob.bramley@arm.com

[commit-bot: I haz the power, 2015-11-19 11:25:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1376173003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1376173003/20001

[commit-bot: I haz the power, 2015-11-19 12:08:03]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-11-19 12:08:22]

Patchset 2 (id:??) landed as
https://crrev.com/dad635ee7ada527cf9d5a0c4317ae1a226876a38
Cr-Commit-Position: refs/heads/master@{#32111}