Improve tracking of the type of fields after object construction

Improve tracking of the type of fields after object construction

Based on the guarenteed types a field is initialized to in both the
initializer lists and constructor bodies give an optimistic type for
this field. Based on all the field setters and invoked setters for
that field turn this optimistic type into either a propagated type or
a guarenteed type.

R=kasperl@google.com, floitsch@google.com

BUG=
TEST=

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

[floitsch, 2012-06-22 08:18:12]

LGTM with one question/comment (null-inits).

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/compiler.dart:60: final Map<Element, Map<Element,
HType>> fieldConstructorSetters;
Do we need this two-stage approach? Shouldn't it be enough to have a mapping
from FieldElement to HType?

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/compiler.dart:160: // Check if this field set in the
constructor body.
is set

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/ssa/optimize.dart:1215:
!compiler.codegenWorld.hasInvokedSetter(field, compiler)) {
what about implicit null-initializations?

[Søren Gjesse, 2012-06-22 09:22:36]

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/compiler.dart:60: final Map<Element, Map<Element,
HType>> fieldConstructorSetters;
On 2012/06/22 08:18:12, floitsch wrote:
> Do we need this two-stage approach? Shouldn't it be enough to have a mapping
> from FieldElement to HType?

The reason for this is that we know that field will be called for all fields for
all constructors. For constructor bodies we cannot tell. Therefore I have this
special handling is a field is set in the constructor body and there is only one
constructor we can still do something.

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/compiler.dart:160: // Check if this field set in the
constructor body.
On 2012/06/22 08:18:12, floitsch wrote:
> is set

Done.

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/ssa/optimize.dart:1215:
!compiler.codegenWorld.hasInvokedSetter(field, compiler)) {
On 2012/06/22 08:18:12, floitsch wrote:
> what about implicit null-initializations?

All the implicit null initialized fields will be in the collected information
and indicate a null value. As fas as I can see this just works, e.g.


class A {
  var _x;
  var _y;

  A() : _x = 2;
  A.b();

  get x() => _x;
  get y() => _y;
}

main () {
  var a = new A();
  var ab = new A.b();
  print(a.x);
  print(a.y);
  print(ab.x);
  print(ab.y);
}

here _x will have guaranteedType "integer or null" and _y guaranteedType "null"

[ngeoffray, 2012-07-09 21:17:41]

DBC

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
File lib/compiler/implementation/ssa/codegen.dart (right):

https://chromiumcodereview.appspot.com/10638013/diff/1/lib/compiler/implement...
lib/compiler/implementation/ssa/codegen.dart:1729:
node.block.dominates(currentGraph.exit)) {
We should probably have a helper method for this instead. Something like
HBasicBlock.isAlwaysExecuted.