Change == into an instance call to allow polymorphic inlining of ==.

Change == into an instance call to allow polymorphic inlining of ==.

In unoptimized code equality is now just another instance call.

The optimizer replaces it with a specialized implementation based on static
 type information and type feedback.

Many of the manual optimizations of == in the optimizer are now just handled
 by the generic inliner, plus polymorphic inlining of == calls is now possible.
This also eliminates the need for a lot of duplicated code in the backend.

I adapted the inlining heuristics to compensate for the slightly larger
inital flow graph size.

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

[Florian Schneider, 2013-10-28 13:34:19]

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
runtime/vm/flow_graph_builder.cc:2960: // Receiver is not a number because
numbers override equality.
I moved the implementation of Object.== here so that the number check can be
eliminated right away (for both unoptimized, and optimized code)

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_in...
File runtime/vm/flow_graph_inliner.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_in...
runtime/vm/flow_graph_inliner.cc:186: if (!call->HasRecognizedTarget() &&
This is needed to avoid performance regressions with our current inlining
heuristics. Long term we should find new parameters that work without these two
checks.

[srdjan, 2013-10-28 21:02:24]

DBC

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
runtime/vm/flow_graph_builder.cc:1366: intptr_t token_pos) {
Should you assert that kind is in valid range?

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_ty...
File runtime/vm/flow_graph_type_propagator.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_ty...
runtime/vm/flow_graph_type_propagator.cc:812: CompileType
EqualityCompareInstr::ComputeType() const {
Please add comment that this is known because EqualityCompareInstr is used only
for known receiver types that are known to return Boolean.

[Kevin Millikin (Google), 2013-10-29 11:26:06]

Looks good to me.

[Florian Schneider, 2013-11-04 10:39:54]

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_bu...
runtime/vm/flow_graph_builder.cc:1366: intptr_t token_pos) {
On 2013/10/28 21:02:25, srdjan wrote:
> Should you assert that kind is in valid range?

I could do it here, but the constructor of StrictCompareInstr already asserts
that.

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_ty...
File runtime/vm/flow_graph_type_propagator.cc (right):

https://codereview.chromium.org/27307005/diff/298001/runtime/vm/flow_graph_ty...
runtime/vm/flow_graph_type_propagator.cc:812: CompileType
EqualityCompareInstr::ComputeType() const {
On 2013/10/28 21:02:25, srdjan wrote:
> Please add comment that this is known because EqualityCompareInstr is used
only
> for known receiver types that are known to return Boolean.

Done.

[fschneider, 2013-11-04 11:33:17]

Committed patchset #8 manually as r29800 (presubmit successful).