[turbofan] Use heavy-handed graph duplication to do loop peeling for OSR.

[turbofan] Use heavy-handed graph duplication to do loop peeling for OSR.

BUG=

Committed: https://crrev.com/31637fb39679eb3b8a28b65d7f8719003e2830fe
Cr-Commit-Position: refs/heads/master@{#26576}

[titzer, 2015-02-09 18:37:48]

titzer@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Michael Starzinger, 2015-02-10 15:28:22]

LGTM with comments.

https://codereview.chromium.org/898353002/diff/20001/src/compiler/loop-analys...
File src/compiler/loop-analysis.cc (right):

https://codereview.chromium.org/898353002/diff/20001/src/compiler/loop-analys...
src/compiler/loop-analysis.cc:470: return first->InputAt(first->InputCount() -
1);
nit: Can we use NodeProperties::GetControlInput here?

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc
File src/compiler/osr.cc (right):

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc#newc...
src/compiler/osr.cc:105: const int backedges = loop_header->InputCount() - 1;
nit: Can we add a DCHECK that loop_header in fact is IrOpcode::kLoopHeader and
use Operator::ControlInputCount here?

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc#newc...
src/compiler/osr.cc:115: // Complex case. Multiple backedges. Introduce a merge
for incoming edges.
Just out of curiosity: When does this actually happen, the graph builder
currently shouldn't construct this case. Also osr-backedges1.js doesn't trigger
it. Do we have test coverage for it?

[titzer, 2015-02-11 13:01:14]

New patchsets have been uploaded after l-g-t-m from mstarzinger@chromium.org

[titzer, 2015-02-11 13:03:35]

https://codereview.chromium.org/898353002/diff/20001/src/compiler/loop-analys...
File src/compiler/loop-analysis.cc (right):

https://codereview.chromium.org/898353002/diff/20001/src/compiler/loop-analys...
src/compiler/loop-analysis.cc:470: return first->InputAt(first->InputCount() -
1);
On 2015/02/10 15:28:21, Michael Starzinger wrote:
> nit: Can we use NodeProperties::GetControlInput here?

Done.

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc
File src/compiler/osr.cc (right):

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc#newc...
src/compiler/osr.cc:105: const int backedges = loop_header->InputCount() - 1;
On 2015/02/10 15:28:21, Michael Starzinger wrote:
> nit: Can we add a DCHECK that loop_header in fact is IrOpcode::kLoopHeader and
> use Operator::ControlInputCount here?

Done.

https://codereview.chromium.org/898353002/diff/20001/src/compiler/osr.cc#newc...
src/compiler/osr.cc:115: // Complex case. Multiple backedges. Introduce a merge
for incoming edges.
On 2015/02/10 15:28:21, Michael Starzinger wrote:
> Just out of curiosity: When does this actually happen, the graph builder
> currently shouldn't construct this case. Also osr-backedges1.js doesn't
trigger
> it. Do we have test coverage for it?

You're right, it doesn't trigger for the graphs coming out of the AST builder,
but this may happen if we add some new optimizations. I've added a cctest which
a carefully hand-constructed graph to test this (and found bugs! and fixed
them!)

[titzer, 2015-02-11 13:04:58]

The CQ bit was checked by titzer@chromium.org

[commit-bot: I haz the power, 2015-02-11 13:05:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/898353002/60001

[commit-bot: I haz the power, 2015-02-11 13:26:40]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-02-11 13:26:56]

Patchset 4 (id:??) landed as
https://crrev.com/31637fb39679eb3b8a28b65d7f8719003e2830fe
Cr-Commit-Position: refs/heads/master@{#26576}