Fix bug in field type tracking and polymorphic inlining.

Fix bug in field type tracking and polymorphic inlining.

When inlining implicit getters via the polymorphic inliner
(and not through the flow graph optimizer) the fields loaded
must be added to the list of guarded fields that trigger
deoptimization when a store violated the field type guard.

Also, this CL avoids adding fields to the list from inlining
candidates that do not get inlined after all. Previously, the
optimizer pass on the callee graph would add guarded fields
even if the final graph does not get inlined.

TEST=tests/language/vm/optimized_guarded_field_test.dart
R=kmillikin@google.com

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

[Florian Schneider, 2013-09-18 12:49:55]

Instead of only passing the list of guarded fields to the FlowGraphOptimizer, I
pass it on to the FlowGraphBuilder, so that fields get properly added while
inlining.

[Kevin Millikin (Google), 2013-09-18 13:03:59]

https://codereview.chromium.org/24096018/diff/1/runtime/vm/flow_graph_builder.cc
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/24096018/diff/1/runtime/vm/flow_graph_builder...
runtime/vm/flow_graph_builder.cc:3058: if (owner()->exit_collector() != NULL) {
Won't this register too many guarded fields --- including all those for inlined
functions rejected after building the graph?  It would be better to add these
when integrating the function into the caller graph, not when building the
potentially-inlined function graph.

I don't know if it matters here, but that would also make it simple to sort the
two lists and then merge, rather than the quadratic check for duplicates.

[Florian Schneider, 2013-09-18 13:32:37]

https://codereview.chromium.org/24096018/diff/1/runtime/vm/flow_graph_builder.cc
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/24096018/diff/1/runtime/vm/flow_graph_builder...
runtime/vm/flow_graph_builder.cc:3058: if (owner()->exit_collector() != NULL) {
On 2013/09/18 13:03:59, kmillikin wrote:
> Won't this register too many guarded fields --- including all those for
inlined
> functions rejected after building the graph?  It would be better to add these
> when integrating the function into the caller graph, not when building the
> potentially-inlined function graph.
> 
> I don't know if it matters here, but that would also make it simple to sort
the
> two lists and then merge, rather than the quadratic check for duplicates.

That's a good idea. I'll add the callee's guarded fields to the caller's guarded
fields only after it is decided that the callee will be inlined.

[Florian Schneider, 2013-09-19 10:45:33]

Uploaded new patch. Please take a look.

[Kevin Millikin (Google), 2013-09-19 10:52:38]

lgtm

[Florian Schneider, 2013-09-19 11:21:54]

Committed patchset #2 manually as r27655 (presubmit successful).