Optimize away most implicit const getter functions

Optimize away most implicit const getter functions

If a static field has a very simple initializer expression
(a literal number or string for example) we initialize the field
directly while compiling instead of generating an implicit
getter. We only do this if the type of the expression is
assignment compatible with the field. If the expression is not
compatible, we let the implicit getter do the error checking.

This eliminates about 330 implicit getters in the core libraries
and saves 35k in the snapshot (830k, down from 865k).
Committed: https://code.google.com/p/dart/source/detail?r=10098

[regis, 2012-07-31 23:19:54]

LGTM

http://codereview.chromium.org/10826090/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (left):

http://codereview.chromium.org/10826090/diff/1/runtime/vm/object.cc#oldcode1499
runtime/vm/object.cc:1499: (field.value() == Object::sentinel()));
Is there any way you can relax this assert rather than delete it?

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

http://codereview.chromium.org/10826090/diff/1/runtime/vm/parser.cc#newcode2535
runtime/vm/parser.cc:2535: bool have_simple_literal = false;
has_simple_literal?

http://codereview.chromium.org/10826090/diff/1/runtime/vm/parser.cc#newcode4505
runtime/vm/parser.cc:4505: *value = CurrentLiteral()->raw();
Not specific to this change list, but it feels strange that CurrentLiteral()
does not return a raw pointer as CurrentIntegerLiteral() and
CurrentDoubleLiteral() both do, and also that it is not called
CurrentStringLiteral().

[hausner, 2012-07-31 23:34:03]

Thank you!

http://codereview.chromium.org/10826090/diff/1/runtime/vm/object.cc
File runtime/vm/object.cc (left):

http://codereview.chromium.org/10826090/diff/1/runtime/vm/object.cc#oldcode1499
runtime/vm/object.cc:1499: (field.value() == Object::sentinel()));
On 2012/07/31 23:19:54, regis wrote:
> Is there any way you can relax this assert rather than delete it?

I tried this at first, but it is actually impossible to check what the comment
implies.

What this assert did was check that if a field is static final, the value must
be sentinel. With my change, the value would be sentinel or anything else. Thus,
the assert became pointless.

Reversing the assert so it checks that if the value is sentinel, the field must
be static const does not work because if you reference the value of a non-static
field, you run into another assertion.

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

http://codereview.chromium.org/10826090/diff/1/runtime/vm/parser.cc#newcode2535
runtime/vm/parser.cc:2535: bool have_simple_literal = false;
On 2012/07/31 23:19:54, regis wrote:
> has_simple_literal?

Done.

http://codereview.chromium.org/10826090/diff/1/runtime/vm/parser.cc#newcode4505
runtime/vm/parser.cc:4505: *value = CurrentLiteral()->raw();
On 2012/07/31 23:19:54, regis wrote:
> Not specific to this change list, but it feels strange that CurrentLiteral()
> does not return a raw pointer as CurrentIntegerLiteral() and
> CurrentDoubleLiteral() both do, and also that it is not called
> CurrentStringLiteral().
True. CurrentLiteral used to return a pointer to a handle that already existed
in the token stream, so we could avoid allocating an unnecessary handle. Somehow
this code changed. I think Siva has already looked at this and concluded that
returning a raw pointer is less ideal but I don't remember why.