A64: Tidy up Push and Pop TODOs.

A64: Tidy up Push and Pop TODOs.

This addresses several TODOs:
  - Push and Pop requests can be queued up so that arrays of Registers
    can be pushed efficiently, with just one PrepareForPush/Pop.
  - PushMultipleTimes now takes an Operand. This allows variable-length
    arguments arrays to be initialized, for example.
  - A NoUseRealAbortsScope has been added to Abort so that
    AssertStackConsistency can be called from PrepareForPush without
    introducing infinite recursion.

BUG=
R=rmcilroy@chromium.org, ulan@chromium.org

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

[ulan, 2014-02-18 15:52:50]

lgtm

[rmcilroy, 2014-02-18 16:35:13]

On 2014/02/18 15:52:50, ulan wrote:
> lgtm

lgtm

[jbramley, 2014-02-19 09:29:23]

On 2014/02/18 16:35:13, rmcilroy wrote:
> On 2014/02/18 15:52:50, ulan wrote:
> > lgtm
> 
> lgtm

Sorry, I found a regression on mjsunit/regress/regress-165637 so I need to
investigate.

[jbramley, 2014-02-19 09:39:36]

On 2014/02/19 09:29:23, jbramley wrote:
> On 2014/02/18 16:35:13, rmcilroy wrote:
> > On 2014/02/18 15:52:50, ulan wrote:
> > > lgtm
> > 
> > lgtm
> 
> Sorry, I found a regression on mjsunit/regress/regress-165637 so I need to
> investigate.

Never mind; I can't reproduce it.

[jbramley, 2014-02-19 09:43:55]

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

[ulan, 2014-02-19 13:04:30]

This regressed several tests in debug snapshot=off build.

For example:
./out/a64.debug/d8 --test --nobreak-on-abort --nodead-code-elimination
--nofold-constants --enable-slow-asserts --debug-code --verify-heap
--allow-natives-syntax --nodead-code-elimination --nofold-constants --nouse-gvn
./test/mjsunit/mjsunit.js ./test/mjsunit/regress/regress-2612.js

#
# Fatal error in ../src/a64/assembler-a64.cc, line 563
# CHECK((num_pending_reloc_info_ == 0) || (pc_offset() < (first_const_pool_use_
+ kMaxDistToPool))) failed
#

There also bunch of cctests failing with:

#
# Fatal error in ../src/a64/assembler-a64.cc, line 2342
# external code buffer is too small
#

[jbramley, 2014-02-19 13:23:37]

On 2014/02/19 13:04:30, ulan wrote:
> This regressed several tests in debug snapshot=off build.

Sorry!

> For example:
> ./out/a64.debug/d8 --test --nobreak-on-abort --nodead-code-elimination
> --nofold-constants --enable-slow-asserts --debug-code --verify-heap
> --allow-natives-syntax --nodead-code-elimination --nofold-constants
--nouse-gvn
> ./test/mjsunit/mjsunit.js ./test/mjsunit/regress/regress-2612.js
> 
> #
> # Fatal error in ../src/a64/assembler-a64.cc, line 563
> # CHECK((num_pending_reloc_info_ == 0) || (pc_offset() <
(first_const_pool_use_
> + kMaxDistToPool))) failed
> #

That happens because that test calls PushMultipleTimes with a huge 'count'.
PushHelper has an InstructionAccurateScope, which prevents the constant pool
from being emitted, but there is no unrestricted region because
InstructionAccurateScope doesn't call CheckConstPool itself. (PushHelper doesn't
actually need InstructionAccurateScope, but I'm working on a fix for that
independently. We should still fix InstructionAccurateScope.)

I can fix InstructionAccurateScope quickly.

> There also bunch of cctests failing with:
> 
> #
> # Fatal error in ../src/a64/assembler-a64.cc, line 2342
> # external code buffer is too small
> #

That's trickier to fix, but I'll investigate. I might have to temporarily
disable the AssertStackConsistency in PrepareForPush, since that's what
triggered this problem the first time around (with snapshots enabled). I'm
currently running the cctests with snapshots=off but I haven't hit a failing
test yet.

[jbramley, 2014-02-19 13:24:13]

On 2014/02/19 13:04:30, ulan wrote:
> This regressed several tests in debug snapshot=off build.

Do I need to revert it?

[ulan, 2014-02-19 13:27:00]

> Do I need to revert it?
It depends on whether there is a quick fix or not. If fix takes more than hour,
it is probably better to revert and work on it without pressure.

[jbramley, 2014-02-19 14:47:27]

On 2014/02/19 13:27:00, ulan wrote:
> > Do I need to revert it?
> It depends on whether there is a quick fix or not. If fix takes more than
hour,
> it is probably better to revert and work on it without pressure.

Fixed here, all being well: https://codereview.chromium.org/172453002/