CpuProfiler: fix for CollectDeoptEvents test on arm64

CpuProfiler: fix for CollectDeoptEvents test on arm64

We use slightly different schema for JumpTable on arm64 than for x64.

We do a branch (B) to the JumpTable from the code,
then a branch (B) to the end of jump table code
and then branch to the deoptimizer code with putting
the return address into lr register (Call which is actually Blr).

As a result the 'from' address in Deoptimizer always points to
the end of JumpTable code and we can get nothing from this information.

0) I moved save_doubles and needs_frame code out of for_loop.

1) I replaced B commands with Bl so we put different return addresses
to lr register for the different jump table entries and replaced
the final Call with Br which do not touch lr register.

Also I removed the last_entry check so we will always do the Bl
even for the last entry because we need the right address in lr.
I don't think that this will affect the performance because it
just one more branch for entire deopt mechanics.

BUG=chromium:452067
LOG=n

Committed: https://crrev.com/82e6824eb725205ffaac925a55e628e5081c7bd7
Cr-Commit-Position: refs/heads/master@{#27094}

[loislo, 2015-03-09 15:34:04]

loislo@chromium.org changed reviewers:
+ alph@chromium.org, svenpanne@chromium.org, yurys@chromium.org

[loislo, 2015-03-09 15:34:05]

PTAL

[Sven Panne, 2015-03-10 07:34:29]

svenpanne@chromium.org changed reviewers:
+ jacob.bramley@arm.com

[Sven Panne, 2015-03-10 07:34:30]

LGTM from my side, but let's wait for Jacob to have a look at
lithium-codegen-arm64.cc.

[jbramley, 2015-03-10 09:53:27]

LGTM

There is usually a penalty associated with corrupting the return stack
predictor. That is, making a call (blr) should usually have a corresponding
return (ret) to the call site. However, we didn't do that correctly before this
patch anyway, so I don't think this patch will make any difference.

It might be nice if we could pass `entry_offset` to `deopt_entry` as a proper
parameter, but it's probably not terribly important, and making a
machine-specific exception to the way that they're handled would be a bit ugly.
If we're deoptimising, we're already not on the fast path.

[loislo, 2015-03-10 10:07:48]

The CQ bit was checked by loislo@chromium.org

[loislo, 2015-03-10 10:07:49]

The patchset sent to the CQ was uploaded after l-g-t-m from
svenpanne@chromium.org
Link to the patchset: https://codereview.chromium.org/984893003/#ps20001 (title:
"support dept tracking for frameless and save_doubles entries")

[commit-bot: I haz the power, 2015-03-10 10:09:40]

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

[commit-bot: I haz the power, 2015-03-10 10:45:11]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-10 10:45:29]

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

[jbramley, 2015-03-10 13:11:18]

https://codereview.chromium.org/984893003/diff/20001/src/arm64/lithium-codege...
File src/arm64/lithium-codegen-arm64.cc (right):

https://codereview.chromium.org/984893003/diff/20001/src/arm64/lithium-codege...
src/arm64/lithium-codegen-arm64.cc:870: __ Push(lr, fp, cp);
We can save some space here by pushing (lr, fp) here, then (cp, stub_marker) at
needs_frame. ARM64 pushes registers in pairs, so pushing (a,b),(c,d) is more
space-efficient than pushing (a,b,c),(d).

The effect is probably small but I'll make a patch to address this, since there
is basically no cost.

(Sorry, I didn't see it at first.)

[loislo, 2015-03-10 14:42:18]

https://codereview.chromium.org/984893003/diff/20001/src/arm64/lithium-codege...
File src/arm64/lithium-codegen-arm64.cc (right):

https://codereview.chromium.org/984893003/diff/20001/src/arm64/lithium-codege...
src/arm64/lithium-codegen-arm64.cc:870: __ Push(lr, fp, cp);
On 2015/03/10 13:11:18, jbramley wrote:
> We can save some space here by pushing (lr, fp) here, then (cp, stub_marker)
at
> needs_frame. ARM64 pushes registers in pairs, so pushing (a,b),(c,d) is more
> space-efficient than pushing (a,b,c),(d).
> 
> The effect is probably small but I'll make a patch to address this, since
there
> is basically no cost.
> 
> (Sorry, I didn't see it at first.)

I'll do this in https://codereview.chromium.org/995813002/