[turbofan] Simplified splintering code.

A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

BUG=

Committed: https://crrev.com/be7e43614c1d7ce63a91b69d7a4bff01d5a74d10
Cr-Commit-Position: refs/heads/master@{#32302}

[Mircea Trofin, 2015-11-24 05:59:16]

Description was changed from

==========
Better splintering

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

to

==========
A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the 
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate 
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

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

[Mircea Trofin, 2015-11-24 05:59:16]

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

[Jarin, 2015-11-25 10:33:08]

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.cc
File src/compiler/pipeline.cc (right):

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.c...
src/compiler/pipeline.cc:847: struct MarkSpilledOnlyInDeferredPhase {
I think there is no need to introduce a new phase for this. It could be done as
part of MergeSplintersPhase.

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.c...
src/compiler/pipeline.cc:854: for (TopLevelLiveRange* top : data->live_ranges())
{
The pipeline should not know about implementation details, such as the live
range data structure. The code here should be moved to a method of the register
allocator and the method should be called from here.

[Mircea Trofin, 2015-11-25 16:21:36]

Addressed feedback.

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.cc
File src/compiler/pipeline.cc (right):

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.c...
src/compiler/pipeline.cc:847: struct MarkSpilledOnlyInDeferredPhase {
On 2015/11/25 10:33:08, Jarin wrote:
> I think there is no need to introduce a new phase for this. It could be done
as
> part of MergeSplintersPhase.

It can be done, but it seemed cleaner to have it separate - merged it in for
now, because I can't find a better defense for separation than "it seems
cleaner".

https://codereview.chromium.org/1472803004/diff/60001/src/compiler/pipeline.c...
src/compiler/pipeline.cc:854: for (TopLevelLiveRange* top : data->live_ranges())
{
On 2015/11/25 10:33:08, Jarin wrote:
> The pipeline should not know about implementation details, such as the live
> range data structure. The code here should be moved to a method of the
register
> allocator and the method should be called from here.

done as a side-effect of addressing the above.

[Jarin, 2015-11-25 19:23:39]

lgtm.

https://codereview.chromium.org/1472803004/diff/80001/src/compiler/register-a...
File src/compiler/register-allocator.h (right):

https://codereview.chromium.org/1472803004/diff/80001/src/compiler/register-a...
src/compiler/register-allocator.h:795: bool
RangesDefinedInDeferredStaysInDeferred();
Stays -> Stay

[Mircea Trofin, 2015-11-25 19:31:39]

The CQ bit was checked by mtrofin@chromium.org

[Mircea Trofin, 2015-11-25 19:31:39]

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

[commit-bot: I haz the power, 2015-11-25 19:31:48]

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

[commit-bot: I haz the power, 2015-11-25 20:07:58]

Description was changed from

==========
A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the 
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate 
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

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

to

==========
A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the 
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate 
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

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

[commit-bot: I haz the power, 2015-11-25 20:07:59]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-11-25 20:08:17]

Description was changed from

==========
A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the 
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate 
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

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

to

==========
A simpler way to determine if a range spills only in deferred blocks, by
validating that the hot path does not spill - somewhat simpler code.

Cleared the scenario where a range is defined in a deferred block. The
code before was slightly more complicated by not leveraging the
property that these sort of ranges would be completely contained within
deferred blocks.

Moved "spills in deferred blocks" marking to a more appropriate
location.

One thing this CL achieves is correct support for scenarios where a
range is spilled both on the deferred and then hot path, and the ranges
concatenate. I owe better unit testing, which I will add in a subsequent
CL.

BUG=

Committed: https://crrev.com/be7e43614c1d7ce63a91b69d7a4bff01d5a74d10
Cr-Commit-Position: refs/heads/master@{#32302}
==========

[commit-bot: I haz the power, 2015-11-25 20:08:18]

Patchset 6 (id:??) landed as
https://crrev.com/be7e43614c1d7ce63a91b69d7a4bff01d5a74d10
Cr-Commit-Position: refs/heads/master@{#32302}