Start creating a MemberSet abstraction, and use it to fold getters/setters into field accesses.

Start creating a MemberSet abstraction, and use it to fold getters/setters into field accesses.
Committed: https://code.google.com/p/dart/source/detail?r=7451

[kasperl, 2012-05-09 08:04:23]

LGTM, but I'd like to have you discuss the member set stuff you added to
Universe and the Compiler.computeSubclasses method with Peter. 

Maybe moving the functionality to a different file and make them members of a
different class will make it easier to clarify the API and start hacking on a
solution for computing member sets that does not require running through *all*
classes.

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
File lib/compiler/implementation/ssa/nodes.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
lib/compiler/implementation/ssa/nodes.dart:1233:
HFieldSet.fromActivation(SourceString this.name, HInstruction value)
I think the spec has been updated to "infer" the type of this.x style
constructor parameters from the field definition. It is fine for to keep the
type here for consistency, but I think we should be moving away from them.

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
File lib/compiler/implementation/universe.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
lib/compiler/implementation/universe.dart:68: * selector named [member] on a
receiver whose type is [type].
Wouldn't it be more logical to let this be parameterized by a selector (possibly
a typed one?).

[ngeoffray, 2012-05-09 10:07:57]

Thank you Kasper. PTAL

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
File lib/compiler/implementation/ssa/nodes.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
lib/compiler/implementation/ssa/nodes.dart:1233:
HFieldSet.fromActivation(SourceString this.name, HInstruction value)
On 2012/05/09 08:04:23, kasperl wrote:
> I think the spec has been updated to "infer" the type of this.x style
> constructor parameters from the field definition. It is fine for to keep the
> type here for consistency, but I think we should be moving away from them.

OK, I removed the type on these constructors.

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
File lib/compiler/implementation/universe.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/4001/lib/compiler/implem...
lib/compiler/implementation/universe.dart:68: * selector named [member] on a
receiver whose type is [type].
On 2012/05/09 08:04:23, kasperl wrote:
> Wouldn't it be more logical to let this be parameterized by a selector
(possibly
> a typed one?).

Yes, that's what I started with. But right now, the typed selector would be
created only to call this method. So I'd rather wait on starting having multiple
users of the API before settling on it.

[kasperl, 2012-05-09 11:13:03]

LGTM!

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:305: computeSubclasses();
Could we move this code to world? That would seem logical to me. Maybe something
like:

world.populate(universe.libraries);

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/ssa/optimize.dart:562: MemberSet memberSet =
compiler.world.memberSetFor(type, node.name);
I would actually consider not using a MemberSet here. Maybe just do:

  compiler.world.isOnlyFields(type, node.name)?

That way it would be easier to cache information in the world and the API that
the compiler depends on what be narrower.

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/world.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/world.dart:14: MemberSet memberSetFor(Type type,
SourceString member) {
I'm not sure this functionality needs to be exposed directly to the optimizer.

[ngeoffray, 2012-05-09 11:34:21]

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/compiler.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/compiler.dart:305: computeSubclasses();
On 2012/05/09 11:13:03, kasperl wrote:
> Could we move this code to world? That would seem logical to me. Maybe
something
> like:
> 
> world.populate(universe.libraries);

Done.

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/ssa/optimize.dart:562: MemberSet memberSet =
compiler.world.memberSetFor(type, node.name);
On 2012/05/09 11:13:03, kasperl wrote:
> I would actually consider not using a MemberSet here. Maybe just do:
> 
>   compiler.world.isOnlyFields(type, node.name)?
> 
> That way it would be easier to cache information in the world and the API that
> the compiler depends on what be narrower.

Done.

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
File lib/compiler/implementation/world.dart (right):

https://chromiumcodereview.appspot.com/10383065/diff/3009/lib/compiler/implem...
lib/compiler/implementation/world.dart:14: MemberSet memberSetFor(Type type,
SourceString member) {
On 2012/05/09 11:13:03, kasperl wrote:
> I'm not sure this functionality needs to be exposed directly to the optimizer.

Made it library private.