Implement StaticCall and InstanceCall in the new code generator.

Implement StaticCall and InstanceCall in the new code generator.

1. Introduce a value visitor for argument values.

2. Add enough information to StaticCallComp and InstanceCallComp IL
computations so that we can generate code.

3. Enable code generation for them.

R=srdjan@google.com
BUG=
TEST=

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

[srdjan, 2012-03-01 17:16:56]

LGTM

http://codereview.chromium.org/9564006/diff/1/runtime/vm/flow_graph_builder.cc
File runtime/vm/flow_graph_builder.cc (right):

http://codereview.chromium.org/9564006/diff/1/runtime/vm/flow_graph_builder.c...
runtime/vm/flow_graph_builder.cc:272: Append(for_right_value);
Why don't you materialize the constants for strict equality check as well? You
could share the ArgumentGraphVisitor between both cases as it was similar with
ValueGraphVisitor before.

[srdjan, 2012-03-01 17:50:12]

One more question.

https://chromiumcodereview.appspot.com/9564006/diff/1/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.h (right):

https://chromiumcodereview.appspot.com/9564006/diff/1/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.h:157: // language Value.
Why do we need both ArgumentGraphVisitor and ValueGraphVisitor? The only
difference is that one materializes a constant and the other one does not.
Please explain when we should not materialize a constant. It seems simpler to me
if we always deal with temporary values only.

[Kevin Millikin (Google), 2012-03-02 08:03:44]

Thanks for the review.  The short answer to both questions is the same:  don't
focus on the constants, focus on the arguments.  Two points about arguments and
constants:

1. Arguments.  ArgumentGraphVisitor is used for exactly the outgoing arguments
to calls, whether they are constants or some other kind of subexpression.  I'm
not certain what our handling of outgoing arguments will eventually be (our
current treatment is likely too simple, though it's cute).  They are special in
a lot of ways---there are possibly two different frame layouts with different
treatment of them, those frame layouts have to be correlated for deoptimization,
arguments might have type feedback from calls in unoptimized code, they have to
be processed in some way as part of inlining, etc.  We will probably eventually
have to mark them explicitly in the IL, but I've avoided committing to that
until we know how it needs to be used.

So I really think we want one type of visitor for argument subexpressions, and
one for other subexpressions in a non-argument value context.  Even if the AST
doesn't have many of the latter subexpressions, I think it will be wrong to
process them as "the same as actual outgoing arguments" when they are not.

In other words: if the strict equality check actually made a call in the
unoptimized code generator, they would be arguments.  Since it doesn't, they are
not.  (We might want to make it do so, if it was valuable for type feedback or
something, but that's another issue and the system can and should support
operations that don't make calls.)

2. Constants.  Crankshaft requires them in the instruction stream, and it's been
a bad design for a few different reasons.  I've designed this IL to not require
them there (but it does allow them by naming them).  Given that, what should be
the default for unoptimized code?  I claim the default is 'not in the
instruction stream', just because putting them there complicates the optimizing
compiler and makes it do more work (they'll have to be present for bailouts to
unoptimized code).

In any case, I don't think avoiding special ad hoc handling here will avoid
special handling altogether.  My experience is the opposite: by not simplifying
the IL by leaving unnecessary stuff out, in practice you will end up with
special ad hoc handling in several different places in the backend pipeline.