[turbofan] regalloc: model context and function mark as reg-defined.

[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free.

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack.
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame
construction, and let the register allocator spill them. That means they
need to be presented to the register allocator as vanilla live ranges,
with pre-assigned spill slots.

The main challenge there is that not all instructions (mainly, stack checks) list their dependency on these ranges being spilled. In this
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback
that we may see double spills in the case where these live ranges spill
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG=v8:4533
LOG=N

Committed: https://crrev.com/0b1261439b53e8d4302d78ecff04ed8b0c46ae58
Cr-Commit-Position: refs/heads/master@{#32775}

[Mircea Trofin, 2015-12-07 05:27:29]

Patchset #1 (id:1) has been deleted

[Mircea Trofin, 2015-12-07 05:27:38]

Patchset #1 (id:20001) has been deleted

[Mircea Trofin, 2015-12-07 06:15:07]

Description was changed from

==========
[turbofan] regalloc: model context and function mark as reg-defined.


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

to

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
==========

[Mircea Trofin, 2015-12-07 06:15:07]

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

[Jarin, 2015-12-10 18:32:59]

Modulo the overkill data structure, the change lgtm.

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

https://codereview.chromium.org/1501363002/diff/40001/src/compiler/register-a...
src/compiler/register-allocator.h:838: ZoneMap<TopLevelLiveRange*, int>
preassigned_slot_ranges_;
Why is this a ZoneMap? A simple vector of pairs should be sufficient.

[Mircea Trofin, 2015-12-11 02:15:50]

Description was changed from

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
==========

to

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N
==========

[Mircea Trofin, 2015-12-11 02:17:09]

The CQ bit was checked by mtrofin@chromium.org

[Mircea Trofin, 2015-12-11 02:17:09]

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/1501363002/#ps60001
(title: " ")

[commit-bot: I haz the power, 2015-12-11 02:17:14]

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

[Mircea Trofin, 2015-12-11 02:17:18]

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

https://codereview.chromium.org/1501363002/diff/40001/src/compiler/register-a...
src/compiler/register-allocator.h:838: ZoneMap<TopLevelLiveRange*, int>
preassigned_slot_ranges_;
On 2015/12/10 18:32:59, Jarin wrote:
> Why is this a ZoneMap? A simple vector of pairs should be sufficient. 

Duh. Thanks for the catch! Fixed.

[commit-bot: I haz the power, 2015-12-11 02:43:54]

Description was changed from

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N
==========

to

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N
==========

[commit-bot: I haz the power, 2015-12-11 02:43:54]

Committed patchset #2 (id:60001)

[commit-bot: I haz the power, 2015-12-11 02:44:15]

Description was changed from

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we 
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free. 

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack. 
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame 
construction, and let the register allocator spill them. That means they 
need to be presented to the register allocator as vanilla live ranges, 
with pre-assigned spill slots. 

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this 
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback 
that we may see double spills in the case where these live ranges spill 
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N
==========

to

==========
[turbofan] regalloc: model context and function mark as reg-defined.

If we model them as memory operands ("SpillOperands"), as we
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free.

That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack.
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.

The natural choice would be to fully decouple their spilling from frame
construction, and let the register allocator spill them. That means they
need to be presented to the register allocator as vanilla live ranges,
with pre-assigned spill slots.

The main challenge there is that not all instructions (mainly, stack checks)
list their dependency on these ranges being spilled. In this
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback
that we may see double spills in the case where these live ranges spill
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.

BUG= v8:4533
LOG=N

Committed: https://crrev.com/0b1261439b53e8d4302d78ecff04ed8b0c46ae58
Cr-Commit-Position: refs/heads/master@{#32775}
==========

[commit-bot: I haz the power, 2015-12-11 02:44:16]

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