[turbofan] Single entry into deferred regions

[turbofan] Single entry into deferred

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.

This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n

Committed: https://crrev.com/5ae587cfb342f3a845802591a1f4133b5a2849f9
Cr-Commit-Position: refs/heads/master@{#35742}

[Mircea Trofin, 2016-04-22 15:57:34]

Description was changed from

==========
Deferred block entry points

BUG=
==========

to

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=4940
==========

[Mircea Trofin, 2016-04-22 15:57:34]

mtrofin@chromium.org changed reviewers:
+ bmeurer@chromium.org, jarin@chromium.org

[Benedikt Meurer, 2016-04-23 12:00:07]

Description was changed from

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=4940
==========

to

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n
==========

[Benedikt Meurer, 2016-04-23 12:04:50]

LGTM once comments addressed.

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
File src/compiler/register-allocator-verifier.cc (right):

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
src/compiler/register-allocator-verifier.cc:285: // TODO(mtrofin): this check
fails when generating code for
Remove the TODO here.

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
File src/compiler/register-allocator.cc (right):

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
src/compiler/register-allocator.cc:3414: int vreg = iterator.Current();
Stale change?

[Mircea Trofin, 2016-04-23 16:27:08]

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
File src/compiler/register-allocator-verifier.cc (right):

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
src/compiler/register-allocator-verifier.cc:285: // TODO(mtrofin): this check
fails when generating code for
On 2016/04/23 12:04:49, Benedikt Meurer wrote:
> Remove the TODO here.

Done.

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
File src/compiler/register-allocator.cc (right):

https://codereview.chromium.org/1912093005/diff/1/src/compiler/register-alloc...
src/compiler/register-allocator.cc:3414: int vreg = iterator.Current();
On 2016/04/23 12:04:49, Benedikt Meurer wrote:
> Stale change?

Ya, I meant to use vreg in the finder.ArrayFor call below. For some reason, the
debugger (or at least lldb) 
won't show the value of iterator.Current() (or its underlying field). Small
change, and helps with debuggability.

[Mircea Trofin, 2016-04-23 16:27:23]

The CQ bit was checked by mtrofin@chromium.org

[Mircea Trofin, 2016-04-23 16:27:24]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1912093005/#ps20001
(title: " ")

[commit-bot: I haz the power, 2016-04-23 16:27:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1912093005/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1912093005/20001

[commit-bot: I haz the power, 2016-04-23 16:56:51]

Description was changed from

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n
==========

to

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n
==========

[commit-bot: I haz the power, 2016-04-23 16:56:52]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-23 16:58:19]

Description was changed from

==========
[turbofan] Single entry into deferred 

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.
 
This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n
==========

to

==========
[turbofan] Single entry into deferred

If a deferred block has multiple predecessors, they have to be
all deferred. Otherwise, we can run into a situation where if a range
that spills only in deferred blocks inserts its spill in the block, and
other ranges need moves inserted by ResolveControlFlow in the predecessors,
the register of the range spilled in the deferred block may be clobbered.

To avoid that, when a deferred block has multiple predecessors, and some
are not deferred, we add a non-deferred block to collect all such edges.

This CL addresses the validator assertion failure the referenced issue, as well
as the greedy allocator failure - which was caused by the situation described
above.

BUG=v8:4940
LOG=n

Committed: https://crrev.com/5ae587cfb342f3a845802591a1f4133b5a2849f9
Cr-Commit-Position: refs/heads/master@{#35742}
==========

[commit-bot: I haz the power, 2016-04-23 16:58:20]

Patchset 2 (id:??) landed as
https://crrev.com/5ae587cfb342f3a845802591a1f4133b5a2849f9
Cr-Commit-Position: refs/heads/master@{#35742}