Implement more of allocation code using type arguments. Type argument extraction for non-factories …

Implement more of allocation code using type arguments. Type argument extraction for non-factories produces two results, however, instructions can produce only one temporary. Use a stack placeholder so that we have room to push two results. Examples of generated IL (first factory, second non-factory).

  foo() { return new List<T>(); }
  moo() { return new A<T>(); }

==== file:///sources/dartall/dart/runtime/Test.dart_A_foo
 0: [target]
    t1 <- LoadLocal(this)
    t1 <- NativeLoadField(t1, 16)
    t1 <- ExtractTypeArguments(t1)
    t0 <- StaticCall(List., t0)
    return t0
==== file:///sources/dartall/dart/runtime/Test.dart_A_moo
 0: [target]
    t0 <- #null
    t1 <- LoadLocal(this)
    t1 <- NativeLoadField(t1, 16)
    t1 <- ExtractTypeArguments(t1)
    t0 <- AllocateObject(Library:'file:///sources/dartall/dart/runtime/Test.dart' Class: A, t0, t1)
    t1 <- Pick(t0)
    t2 <- #3
    StaticCall(A., t1, t2)
    return t0
Committed: https://code.google.com/p/dart/source/detail?r=5480

[regis, 2012-03-14 18:30:04]

LGTM

You can submit now and we can refactor the code so that ExtractTypeArguments
does not produce two values.

I would start by duplicating the code for the constructor and factory cases.
EffectGraphVisitor::BuildTypeArguments would become
EffectGraphVisitor::BuildConstructorTypeArguments and
EffectGraphVisitor::BuildFactoryTypeArguments.

Then, EffectGraphVisitor::GenerateInstantiatorTypeArguments would be split as
well to EffectGraphVisitor::GenerateFactoryTypeArguments and
EffectGraphVisitor::GenerateConstructorInstantiatorTypeArguments.

The new EffectGraphVisitor::GenerateConstructorInstantiatorTypeArguments would
call 2 functions, each one generating a single value:
GenerateConstructorInstantiatorComp and
ExtractConstructorTypeArgumentsComp

whereas EffectGraphVisitor::GenerateFactoryTypeArguments
would only call GenerateFactoryTypeArgumentsComp.

If you'd like, I can give this a try after you submit this change.

I wonder if we should split this in code_generator_x64.cc as  well.

-- Regis

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

https://chromiumcodereview.appspot.com/9700003/diff/1/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.h:120: Value*
GenerateInstantiatorTypeArguments(intptr_t token_index,
GenerateInstantiatorTypeArguments and BuildTypeArguments above are missing
comments.

[srdjan, 2012-03-14 18:48:34]

Thanks for the review. It would be great if you could tackle the splitting as
you suggested.

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

https://chromiumcodereview.appspot.com/9700003/diff/1/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.h:120: Value*
GenerateInstantiatorTypeArguments(intptr_t token_index,
On 2012/03/14 18:30:04, regis wrote:
> GenerateInstantiatorTypeArguments and BuildTypeArguments above are missing
> comments.

Added comments.

  // Creates type arguments (one or two values in 'args') used in preparation
  // of a constructor or factory call.
  // For factory call instantiates and returns type argument vector in 'args'.
  // For constructor call returns type arguments and type arguments of the
  // instantiator.
  // May be called only if allocating an object of a parameterized class.
  void BuildTypeArguments(ConstructorCallNode* node,
                          ZoneGrowableArray<Value*>* args);

  // Returns the value of the type arguments of the instantiator.
  Value* GenerateInstantiatorTypeArguments(intptr_t token_index,
                                           intptr_t type_arguments);