Implement x64 compilation for loading and storing local variables.

Implement x64 compilation for loading and storing local variables.

Continue to bailout on optional parameters and context-allocated local
variables.

Implement compilation of Bind and Do instructions, LoadLocal and StoreLocal
computations, and temporary values.  Temporary allocation assumes they obey
a stack-discipline and have a single use---so any use is always the last
use.  Temporaries can then be allocated via push and used via pop.  This
dart function:

hukairs(a) {
  var b, c;
  c = b = a;
  return c;
}

compiles to this annotated generated code snippet:

	;; StoreLocal(b, #null)
  66:	mov    $0x7f99303c0021,%rax
  70:	mov    %rax,-0x8(%rbp)
	;; StoreLocal(c, #null)
  74:	mov    $0x7f99303c0021,%rax
  7e:	mov    %rax,-0x10(%rbp)
	;; t0 <-LoadLocal(a)
  82:	mov    0x10(%rbp),%ax
  86:	push   %rax
	;; t0 <-StoreLocal(b, t0)
  87:	pop    %rax
  88:	mov    %rax,-0x8(%rbp)
  8c:	push   %rax
	;; StoreLocal(c, t0)
  8d:	pop    %rax
  8e:	mov    %rax,-0x10(%rbp)
	;; t0 <-LoadLocal(c)
  92:	mov    -0x10(%rbp),%ax
  96:	push   %rax
	;; return t0
  97:	pop    %rax
	;; ...
  bf:	mov    %rbp,%rsp
  c2:	pop    %rbp
  c3:	retq

R=srdjan@google.com
BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=4666

[Kevin Millikin (Google), 2012-02-27 13:35:07]

Guide to review:

1. This includes the changes from http://codereview.chromium.org/9471010/
(expand the graph visitor) which will be landed first.

2. We are still not using the generated code.  I put it off because it needs
some learning about Dart's heap and object representation, but I'll take a stab
at it next.

3. I would like to add a way to track stack height (at least in debug builds) so
that we can assert that temporary lifetimes are well-behaved (i.e., can be stack
allocated).  That will wait for a separate change.

4. It shouldn't really bother us right now, but there are a couple of simple
ways to the push/pop that arises from the naive implementation:

a. Modify the compiler to pass a bit to compilation of computations telling
whether we want their value (the occur in a Bind) or not (the occur in a Do) and
move the responsibility of pushing from the Bind instruction into the
computation.

b. Modify the graph translation so their are multiple uses of the same value. 
Instead of

    t0 <-LoadLocal(a)
    t0 <-StoreLocal(b, t0)
    StoreLocal(c, t0)

for 'c = b = a', we would have:

    t0 <-LoadLocal(a)
    StoreLocal(b, t0)
    StoreLocal(c, t0)

with two uses of the same temp t0.  This requires something like reference
counting (following control flow) in the code generator to deallocate on the
last use, so I'm happy to put it off for a very long time.

[Kevin Millikin (Google), 2012-02-27 13:40:41]

http://codereview.chromium.org/9447102/diff/1/runtime/vm/flow_graph_compiler_...
File runtime/vm/flow_graph_compiler_x64.cc (right):

http://codereview.chromium.org/9447102/diff/1/runtime/vm/flow_graph_compiler_...
runtime/vm/flow_graph_compiler_x64.cc:90: __ movw(RAX, Address(RBP,
comp->local().index() * kWordSize));
Oops, movq.

http://codereview.chromium.org/9447102/diff/1/runtime/vm/flow_graph_compiler_...
runtime/vm/flow_graph_compiler_x64.cc:217: __ j(ABOVE, &no_stack_overflow,
Assembler::kNearJump);
I did not make this change (to shorten the encoding) on the existing code
generator.  I was not absolutely sure that this instruction is not patched
somehow.

http://codereview.chromium.org/9447102/diff/1/runtime/vm/scopes.h
File runtime/vm/scopes.h (right):

http://codereview.chromium.org/9447102/diff/1/runtime/vm/scopes.h#newcode60
runtime/vm/scopes.h:60: ASSERT(!HasIndex() || (index_ == index));
There's no simple way to clear variables that have an assigned index when we
bailout of the optimizing compiler.  I modified this function to allow setting
the index as long as it doesn't change.

[srdjan, 2012-02-27 23:23:53]

LGTM

Regarding temporaries: I think that one-use-only rule is good enough for now.
I like the idea of tracking stack height in debug mode an verifying that the
order fo consumption of temporaries is correct (stack heigh 2 means only t1 can
be consumed/popped).

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_builde...
File runtime/vm/flow_graph_builder.cc (right):

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_builde...
runtime/vm/flow_graph_builder.cc:1099: const char* function_name =
parsed_function_.function().ToCString();
You may want to use ToFullyQualifiedCString here.

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_compil...
File runtime/vm/flow_graph_compiler_x64.cc (right):

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_compil...
runtime/vm/flow_graph_compiler_x64.cc:26: const char* function_name =
parsed_function_.function().ToCString();
ToFullyQUalifiedCString if needed.

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_compil...
runtime/vm/flow_graph_compiler_x64.cc:204: // Initialize locals to null.
Shall we generate IL to describe the NULL stores into locals? That way the SSA
builder would be able to remove them.

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/scopes.h
File runtime/vm/scopes.h (right):

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/scopes.h#newcode60
runtime/vm/scopes.h:60: ASSERT(!HasIndex() || (index_ == index));
Add a comment why it can happen that the same index is assigned twice.

[Kevin Millikin (Google), 2012-02-28 09:13:12]

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_compil...
File runtime/vm/flow_graph_compiler_x64.cc (right):

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/flow_graph_compil...
runtime/vm/flow_graph_compiler_x64.cc:204: // Initialize locals to null.
On 2012/02/27 23:23:53, srdjan wrote:
> Shall we generate IL to describe the NULL stores into locals? That way the SSA
> builder would be able to remove them.

It looks like they're already present in the AST, because we're generating IL
for them without any special handling.  I kept this loop from the existing code
generator because I wasn't positive that a GC or other stack walk could
definitely not occur between the prologue code and the explicit null
initialization.

Let's keep it as an open issue to revisit (maybe remove them from the AST?) in a
month or so.

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/scopes.h
File runtime/vm/scopes.h (right):

http://codereview.chromium.org/9447102/diff/4001/runtime/vm/scopes.h#newcode60
runtime/vm/scopes.h:60: ASSERT(!HasIndex() || (index_ == index));
On 2012/02/27 23:23:53, srdjan wrote:
> Add a comment why it can happen that the same index is assigned twice.

Good idea, done.