[turbofan]: Support using push instructions for setting up tail call parameters

[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.

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

[danno, 2016-06-22 09:37:14]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

[danno, 2016-06-22 09:37:14]

danno@chromium.org changed reviewers:
+ bmeurer@chromium.org, epertoso@chromium.org

[danno, 2016-06-22 09:37:54]

This is still a WIP, but was curious about feedback before taking it further.

[Benedikt Meurer, 2016-06-23 04:16:30]

bmeurer@chromium.org changed reviewers:
+ jarin@chromium.org

[danno, 2016-06-29 09:24:39]

PTAL. I cleaned this up and completed the push support on ia32, x64 and ARM
platforms (ARM64 and MIPS don't gain any advantage through generating pushes)

[Benedikt Meurer, 2016-06-29 09:53:35]

bmeurer@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Benedikt Meurer, 2016-06-30 07:57:05]

bmeurer@chromium.org changed reviewers:
+ mtrofin@chromium.org

[Benedikt Meurer, 2016-06-30 07:57:07]

Mircea should probably also have a look at this.
As discussed offline, this is fine with me on a high-level (and seems good on
low-level too, although I wish we could simplify it a bit).
So LGTM from my side, but please wait for feedback from Jaro.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
File src/compiler/gap-resolver.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:40: bool ValidPush(InstructionOperand source,
Nit: IsValidPush

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:60: }  // namespace
Nit: empty line (here and in other places for anonymous namespaces).

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
File src/compiler/x64/code-generator-x64.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
src/compiler/x64/code-generator-x64.cc:682: GapResolver::PushTypeFlags flags =
GapResolver::kImmediatePush;
Nit: Merge these two lines.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
src/compiler/x64/code-generator-x64.cc:687: if (pushes.size() > 0 &&
Nit: !pushes.empty()

[Mircea Trofin, 2016-06-30 15:32:34]

LGTM, some comments (in 2 different revisions, it turns out)

please also add an explanation in the CL as to why we'd change moves
to pushes, and why just for tail calls.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
File src/compiler/gap-resolver.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:62: void GapResolver::GetPushCompatibleMoves(Zone*
zone, Instruction* instr,
Is cycles something to worry about?

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:91: // LAST gap don't get clobbered in the FIRST
gap.
The move optimizer should have detected and elided gap position redundancies.
Which problematic case may still arrive here?

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:101: (*pushes)[index] = move;
pushes->at(index) = move rather?

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/arm/code-...
File src/compiler/arm/code-generator-arm.cc (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/arm/code-...
src/compiler/arm/code-generator-arm.cc:459: masm->push((*pending_pushes)[0]);
pending_pushes->at(0) 

same further down and elsewhere.

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/code-gene...
File src/compiler/code-generator.h (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/code-gene...
src/compiler/code-generator.h:141: void AssemblePreGaps(Instruction* instr);
Code comment on what these do.

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/gap-resol...
File src/compiler/gap-resolver.h (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/gap-resol...
src/compiler/gap-resolver.h:46: static void GetPushCompatibleMoves(Zone* zone,
Instruction* instr,
Is this just for tail calls cases, or in general?

Could you add a comment as to what specifically makes a move instruction a
candidate to be turned into a 
push?

[danno, 2016-06-30 16:36:04]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location model a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction. On yet other
platforms (ARM64, MIPS), there are no push instructions.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

[danno, 2016-06-30 16:37:42]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location model a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction. On yet other
platforms (ARM64, MIPS), there are no push instructions.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

[Jarin, 2016-06-30 16:48:04]

lgtm.

However, this is what I was worried about when I did not like the tail call
moves being implemented in the gap resolver - this CL is doubling the gap
resolver in size for stuff that has little to do with actually resolving gaps.
It is there just to make tailcalls sequences faster (and prettier). 

As Mircea already suggested, it would be great if comments explained that the
new additions are there for tailcalls. In my opinion, the names should be
changed to hint that, too. WDYT?

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
File src/compiler/arm/code-generator-arm.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
src/compiler/arm/code-generator-arm.cc:450: namespace {
Nit: new line here and at the end of the namespace.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
File src/compiler/gap-resolver.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:101: (*pushes)[index] = move;
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> pushes->at(index) = move rather?

No, please do not use vector::at - it does bounds checks and throws exceptions;
we do not want that.

[Mircea Trofin, 2016-06-30 16:54:48]

On 2016/06/30 16:48:04, Jarin wrote:
> lgtm.
> 
> However, this is what I was worried about when I did not like the tail call
> moves being implemented in the gap resolver - this CL is doubling the gap
> resolver in size for stuff that has little to do with actually resolving gaps.
> It is there just to make tailcalls sequences faster (and prettier). 
> 
> As Mircea already suggested, it would be great if comments explained that the
> new additions are there for tailcalls. In my opinion, the names should be
> changed to hint that, too. WDYT?
> 
>
https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
> File src/compiler/arm/code-generator-arm.cc (right):
> 
>
https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
> src/compiler/arm/code-generator-arm.cc:450: namespace {
> Nit: new line here and at the end of the namespace.
> 
>
https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
> File src/compiler/gap-resolver.cc (right):
> 
>
https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
> src/compiler/gap-resolver.cc:101: (*pushes)[index] = move;
> On 2016/06/30 15:32:34, Mircea Trofin wrote:
> > pushes->at(index) = move rather?
> 
> No, please do not use vector::at - it does bounds checks and throws
exceptions;
> we do not want that.

Should we have then a std::vector<>& ref = *pushes and then ref[]?

[danno, 2016-07-01 07:31:57]

I moved the push detection logic out of gap resolver and tried to address Mircea
and Jaro's high-level feedback. Does that address your concerns?

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
File src/compiler/arm/code-generator-arm.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/arm/code-...
src/compiler/arm/code-generator-arm.cc:450: namespace {
On 2016/06/30 16:48:04, Jarin wrote:
> Nit: new line here and at the end of the namespace.

Done.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
File src/compiler/gap-resolver.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:40: bool ValidPush(InstructionOperand source,
On 2016/06/30 07:57:06, Benedikt Meurer wrote:
> Nit: IsValidPush

Done.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:60: }  // namespace
On 2016/06/30 07:57:06, Benedikt Meurer wrote:
> Nit: empty line (here and in other places for anonymous namespaces).

Done.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:62: void GapResolver::GetPushCompatibleMoves(Zone*
zone, Instruction* instr,
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> Is cycles something to worry about?

Nope, since the test for valid pushes are moves where the destination is at or
above first_push_compatible_index, but at the same time, the code here checks
that there are no sources from moves that are at or above
first_push_compatible_index. This guarantees the pushes are not part of cycles.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:91: // LAST gap don't get clobbered in the FIRST
gap.
On 2016/06/30 15:32:33, Mircea Trofin wrote:
> The move optimizer should have detected and elided gap position redundancies.
> Which problematic case may still arrive here?

Yes. The problem isn't redundancy, it's the fact that stores to the area of the
stack that should be considered for stack pushes can be divided between the two
gaps. The problematic case is that a push from the second gap uses a source
which is set by the first gap. Hoisting that LAST gap push above the FIRST gap
would change the semantic, so it's not allow. However, hoisting other LAST gap
pushes is allowed. Right now, since detecting that case is just more code and
doesn't happen often, this CL simply doesn't hoist.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:101: (*pushes)[index] = move;
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> pushes->at(index) = move rather?

Done.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/gap-resol...
src/compiler/gap-resolver.cc:101: (*pushes)[index] = move;
On 2016/06/30 16:48:04, Jarin wrote:
> On 2016/06/30 15:32:34, Mircea Trofin wrote:
> > pushes->at(index) = move rather?
> 
> No, please do not use vector::at - it does bounds checks and throws
exceptions;
> we do not want that.

OK. Not done :-)

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
File src/compiler/x64/code-generator-x64.cc (right):

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
src/compiler/x64/code-generator-x64.cc:682: GapResolver::PushTypeFlags flags =
GapResolver::kImmediatePush;
On 2016/06/30 07:57:06, Benedikt Meurer wrote:
> Nit: Merge these two lines.

Done.

https://codereview.chromium.org/2082263002/diff/350001/src/compiler/x64/code-...
src/compiler/x64/code-generator-x64.cc:687: if (pushes.size() > 0 &&
On 2016/06/30 07:57:06, Benedikt Meurer wrote:
> Nit: !pushes.empty()

Done.

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/arm/code-...
File src/compiler/arm/code-generator-arm.cc (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/arm/code-...
src/compiler/arm/code-generator-arm.cc:459: masm->push((*pending_pushes)[0]);
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> pending_pushes->at(0) 
> 
> same further down and elsewhere.

Done.

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/code-gene...
File src/compiler/code-generator.h (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/code-gene...
src/compiler/code-generator.h:141: void AssemblePreGaps(Instruction* instr);
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> Code comment on what these do.

Done.

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/gap-resol...
File src/compiler/gap-resolver.h (right):

https://codereview.chromium.org/2082263002/diff/370001/src/compiler/gap-resol...
src/compiler/gap-resolver.h:46: static void GetPushCompatibleMoves(Zone* zone,
Instruction* instr,
On 2016/06/30 15:32:34, Mircea Trofin wrote:
> Is this just for tail calls cases, or in general?
> 
> Could you add a comment as to what specifically makes a move instruction a
> candidate to be turned into a 
> push?

Eventually, I'd like to convert the "normal" call mechanism to use this too, but
there is more prep work to do this. Given how bad the code was for tail calls in
its current from, going this path sets the bar low, allowing some of the
infrastructure in place before switching everything over. I'll explain this in
the overall comment for the CL.

[Jarin, 2016-07-01 09:37:15]

lgtm, I find it quite a bit clearer now. Thanks!

[danno, 2016-07-01 11:03:10]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) are now integrated into the
process
of gap resolving, making it possible to safely recognize gap moves that
are actually pushes.
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
==========

[danno, 2016-07-01 11:04:19]

The CQ bit was checked by danno@chromium.org

[danno, 2016-07-01 11:04:19]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, mtrofin@chromium.org
Link to the patchset: https://codereview.chromium.org/2082263002/#ps450001
(title: "Fix comments")

[commit-bot: I haz the power, 2016-07-01 11:04:22]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-01 11:28:10]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
==========

[commit-bot: I haz the power, 2016-07-01 11:28:11]

Committed patchset #24 (id:450001)

[commit-bot: I haz the power, 2016-07-01 11:28:33]

Description was changed from

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer 
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
==========

to

==========
[turbofan]: Support using push instructions for setting up tail call parameters

This optimizes the passing of stack parameters in function calls.

For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push
instructions,
and this optimization isn't used at all.

Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.

The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.

Committed: https://crrev.com/bd0d9e7d87d418b0c6a84f298e27058645083dad
Cr-Commit-Position: refs/heads/master@{#37477}
==========

[commit-bot: I haz the power, 2016-07-01 11:28:35]

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