[turbofan] Alternative splintering mechanism.

Instead of splintering by chunks of deferred blocks, irrespective of the
range's internal structure, we take a range at a time and splinter based on
the blocks it covers. This is no different in scenarios where a UseInterval
covers non-deferred then deferred blocks. However, in scenarios where
a deferred block jumps to another one, and there are no other blocks
covered by the range in between, this CL will treat the two such blocks
together, while the previous one would treat them separately. This matters
in cases such as deoptimization blocks preceded (not necessarily
consecutively) by a single instruction (jump) Merging block.

Committed: https://crrev.com/27f51390e9e2a1bdf72783ebe2407045815c5ee9
Cr-Commit-Position: refs/heads/master@{#31422}

[Mircea Trofin, 2015-10-20 06:04:57]

Description was changed from

==========
Splinter along ranges


Revert "Revert of [turbofan] Initial support for monomorphic/polymorphic
property loads. (patchset #3 id:100001 of
https://codereview.chromium.org/1396333010/ )"

This reverts commit 5c534812334fe6ab62a8e477620b1c575444b14e.

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

to

==========
Instead of splintering by chunks of deferred blocks, irrespective of the
range's internal structure, we take a range at a time and splinter based on
the blocks it covers. This is no different in scenarios where a UseInterval
covers non-deferred then deferred blocks. However, in scenarios where
a deferred block jumps to another one, and there are no other blocks 
covered by the range in between, this CL will treat the two such blocks 
together, while the previous one would treat them separately. This matters
in cases such as deoptimization blocks preceded (not necessarily 
consecutively) by a single instruction (jump) Merging block.
==========

[Mircea Trofin, 2015-10-20 06:04:57]

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

[Jarin, 2015-10-20 13:12:41]

lgtm with nits.

https://codereview.chromium.org/1415833002/diff/80001/src/compiler/live-range...
File src/compiler/live-range-separator.cc (right):

https://codereview.chromium.org/1415833002/diff/80001/src/compiler/live-range...
src/compiler/live-range-separator.cc:60: if (!(start.IsGapPosition() ||
start.IsStart())) {
I would prefer to say 

if (start.IsInstructionPosition() && start.IsEnd()) ...

here.

https://codereview.chromium.org/1415833002/diff/80001/src/compiler/live-range...
src/compiler/live-range-separator.cc:80: LifetimePosition last_cut =
Does the value of last_cut even matter? Could it be LifetimePosition::Invalid()?
It seems that whenever we set first_cut to valid position, we also set last_cut,
so CreateSplinter should always get a good position.

https://codereview.chromium.org/1415833002/diff/80001/src/compiler/live-range...
src/compiler/live-range-separator.cc:106: last_cut =
LifetimePosition::GapFromInstructionIndex(
last_cut = LifetimePosition::Invalid(); ? (Same as above.)

[Mircea Trofin, 2015-10-20 15:16:11]

Patchset #5 (id:80001) has been deleted

[Mircea Trofin, 2015-10-20 15:56:27]

The CQ bit was checked by mtrofin@chromium.org

[Mircea Trofin, 2015-10-20 15:56:27]

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/1415833002/#ps100001
(title: " ")

[commit-bot: I haz the power, 2015-10-20 15:56:33]

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

[commit-bot: I haz the power, 2015-10-20 16:00:25]

Committed patchset #5 (id:100001)

[commit-bot: I haz the power, 2015-10-20 16:00:46]

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