Migrate {Closure,Instance,Static}Call to use location-based code generation templates.

Migrate {Closure,Instance,Static}Call to use location-based code generation templates.

Calls that have all arguments pushed on the stack can share a common location-summary.
For the (non-optimizing) flow-graph compiler this means:
1. Nothing to do for the inputs.
2. The result is in fixed register RAX.
Committed: https://code.google.com/p/dart/source/detail?r=7833

[srdjan, 2012-05-21 22:58:53]

LGTM

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
File vm/intermediate_language_x64.cc (right):

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
vm/intermediate_language_x64.cc:12: #define __ compiler->assembler()->
For next CLs: Maybe we should use a different class than FlowGraphCompiler for
emitting (the emission functions do not have anything to do with flow graph). A
class named like CodePatterns? Opinions?

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
vm/intermediate_language_x64.cc:80: LocationSummary* result = new
LocationSummary(0);
What about inputs?

[Florian Schneider, 2012-05-21 23:31:15]

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
File vm/intermediate_language_x64.cc (right):

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
vm/intermediate_language_x64.cc:12: #define __ compiler->assembler()->
On 2012/05/21 22:58:53, srdjan wrote:
> For next CLs: Maybe we should use a different class than FlowGraphCompiler for
> emitting (the emission functions do not have anything to do with flow graph).
A
> class named like CodePatterns? Opinions?

Agree. For now until everything is transitioned, let's keep this separate file
to avoid confusion with the other (ia32) code generator.

https://chromiumcodereview.appspot.com/10407077/diff/5001/vm/intermediate_lan...
vm/intermediate_language_x64.cc:80: LocationSummary* result = new
LocationSummary(0);
On 2012/05/21 22:58:53, srdjan wrote:
> What about inputs?

Inputs (in this case outgoing arguments) are assumed to be on the pushed on the
stack. I did not want to introduce a new location-kind like
kOutgoingStackArgument now, since these would be ignored by the instruction
prologue routine FlowGraphCompiler::EmitInstructionPrologue anyway.