[turbofan] Splinter when range ends at hot block start

[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred
blocks. Verified locally that these checks would have tripped in a few
cases before this change.

BUG=

Committed: https://crrev.com/83683e92e1d1cc66d3734da4c7f5229925b0d2de
Cr-Commit-Position: refs/heads/master@{#33301}

[Mircea Trofin, 2016-01-08 19:20:47]

Patchset #3 (id:40001) has been deleted

[Mircea Trofin, 2016-01-14 06:46:11]

Patchset #3 (id:60001) has been deleted

[Mircea Trofin, 2016-01-14 06:46:19]

Patchset #2 (id:20001) has been deleted

[Mircea Trofin, 2016-01-14 06:46:33]

Patchset #1 (id:1) has been deleted

[Mircea Trofin, 2016-01-14 07:11:56]

Description was changed from

==========
[turbofan] Fix splintering when range ends in Gap::END

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

to

==========
We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

[Mircea Trofin, 2016-01-14 07:11:56]

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

[Benedikt Meurer, 2016-01-14 11:51:45]

Description was changed from

==========
We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

to

==========
[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

[Benedikt Meurer, 2016-01-14 11:58:37]

lgtm

[mtrofin, 2016-01-14 16:08:21]

The CQ bit was checked by mtrofin@google.com

[commit-bot: I haz the power, 2016-01-14 16:08:31]

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

[commit-bot: I haz the power, 2016-01-14 16:28:42]

Description was changed from

==========
[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

to

==========
[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

[commit-bot: I haz the power, 2016-01-14 16:28:43]

Committed patchset #1 (id:80001)

[commit-bot: I haz the power, 2016-01-14 16:29:17]

Description was changed from

==========
[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred 
blocks. Verified locally that these checks would have tripped in a few
cases before this change. 

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

to

==========
[turbofan] Splinter when range ends at hot block start

We were sometimes losing a splintering opportunity when a range was
ending at the beginning of a hot (==non-deferred) block, when giving
its value to some fixed range - i.e. a fixed operand of the first instruction
in that hot block.

Renamed 2 APIs to better reflect what their intent is.

Added self-checking when introducing moves connecting ranges, to
ensure we don't spill/fill in hot blocks ranges spilled only in deferred
blocks. Verified locally that these checks would have tripped in a few
cases before this change.

BUG=

Committed: https://crrev.com/83683e92e1d1cc66d3734da4c7f5229925b0d2de
Cr-Commit-Position: refs/heads/master@{#33301}
==========

[commit-bot: I haz the power, 2016-01-14 16:29:18]

Patchset 1 (id:??) landed as
https://crrev.com/83683e92e1d1cc66d3734da4c7f5229925b0d2de
Cr-Commit-Position: refs/heads/master@{#33301}