Infer guaranteed types for static calls that are only called once.

Infer guaranteed types for static calls that are only called once.

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

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

[floitsch, 2012-08-07 13:12:28]

LGTM.

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/lib/compiler/i...
File dart/lib/compiler/implementation/types/types.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/lib/compiler/i...
dart/lib/compiler/implementation/types/types.dart:62: return type;
return null;, and remove type variable.

[kasperl, 2012-08-07 13:39:24]

LGTM.

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/tests/compiler...
File dart/tests/compiler/dart2js/concrete_type_inference_test.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/tests/compiler...
dart/tests/compiler/dart2js/concrete_type_inference_test.dart:82: @'fisk(a, [b,
c]) {} main() { fisk(1); }',
Do you need the @ here?

[ahe, 2012-08-08 08:07:48]

Hi Kasper and Florian,

Thank you for taking a look. I forgot to publish my comments before I committed
this change.

Unfortunately, I had to revert, so I'll reopen this CL to address the issues the
buildbots found.

Cheers,
Peter

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/lib/compiler/i...
File dart/lib/compiler/implementation/types/types.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/lib/compiler/i...
dart/lib/compiler/implementation/types/types.dart:62: return type;
On 2012/08/07 13:12:28, floitsch wrote:
> return null;, and remove type variable.

Done.

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/tests/compiler...
File dart/tests/compiler/dart2js/concrete_type_inference_test.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/2001/dart/tests/compiler...
dart/tests/compiler/dart2js/concrete_type_inference_test.dart:82: @'fisk(a, [b,
c]) {} main() { fisk(1); }',
On 2012/08/07 13:39:24, kasperl wrote:
> Do you need the @ here?

Done.

[ahe, 2012-08-08 12:31:45]

PTAL at "Patch Set 3 : Reviving CL after reverting".

I'm resubmitting this CL without waiting for your review of the tweaks in patch
set 3.

[kasperl, 2012-08-08 12:36:46]

LGTM.

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3299: if (element ===
builder.compiler.boolClass) return HType.BOOLEAN;
I'm a bit worried about how we deal with null here. I think the compiler assumes
that anything that has HType.INTEGER associated with it cannot be null, but I'm
pretty sure that is not the case everywhere we know something has the type
represented with the intClass element.

[ahe, 2012-08-08 12:40:04]

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3299: if (element ===
builder.compiler.boolClass) return HType.BOOLEAN;
On 2012/08/08 12:36:47, kasperl wrote:
> I'm a bit worried about how we deal with null here. I think the compiler
assumes
> that anything that has HType.INTEGER associated with it cannot be null, but
I'm
> pretty sure that is not the case everywhere we know something has the type
> represented with the intClass element.

Right now, I use the intClass to mean the concrete type non-null SMI. I really
should have something like this:

new ConcreteType(compiler.intClass);

[ngeoffray, 2012-08-16 12:55:40]

Very nice

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3302: if (element ===
builder.compiler.listClass) return HType.READABLE_ARRAY;
Why?

[ahe, 2012-08-16 17:15:19]

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3302: if (element ===
builder.compiler.listClass) return HType.READABLE_ARRAY;
On 2012/08/16 12:55:40, ngeoffray wrote:
> Why?

What else would you use?

[ngeoffray, 2012-08-17 07:59:28]

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3302: if (element ===
builder.compiler.listClass) return HType.READABLE_ARRAY;
On 2012/08/16 17:15:19, ahe wrote:
> On 2012/08/16 12:55:40, ngeoffray wrote:
> > Why?
> 
> What else would you use?

HBoundedPotentialPrimitiveArray. A user-defined class that extends List will not
be a readable array. Maybe the assumption here is that it will always be a JS
array (because that's what READABLE_ARRAY is), but this deserves a comment.

[ahe, 2012-08-21 15:05:38]

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
File dart/lib/compiler/implementation/ssa/builder.dart (right):

https://chromiumcodereview.appspot.com/10855020/diff/10001/dart/lib/compiler/...
dart/lib/compiler/implementation/ssa/builder.dart:3302: if (element ===
builder.compiler.listClass) return HType.READABLE_ARRAY;
On 2012/08/17 07:59:28, ngeoffray wrote:
> On 2012/08/16 17:15:19, ahe wrote:
> > On 2012/08/16 12:55:40, ngeoffray wrote:
> > > Why?
> > 
> > What else would you use?
> 
> HBoundedPotentialPrimitiveArray. A user-defined class that extends List will
not
> be a readable array. Maybe the assumption here is that it will always be a JS
> array (because that's what READABLE_ARRAY is), but this deserves a comment.

It will always be a JS array. That is what concrete-type inference is about.

I assume we will get a better infrastructure for this, so we don't use elements
to represent concrete types.