https://codereview.chromium.org/1271703002/diff/60001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1271703002/diff/60001/src/compiler/register-allocator.cc#newcode392
src/compiler/register-allocator.cc:392: move->AddMove(assigned,
spill_operand);
On 2015/08/04 20:34:46, Mircea Trofin wrote:
On 2015/08/04 19:39:43, Jarin wrote:
> Still confused about this - where do we actually spill the deferred
block with
a
> call? This move seems to be only inserted for ranges that are not
spilled.
Correct. It sets up the stage for the register allocator. The register
allocator
will make the decision of where to spill, but now it will treat the
segments
over deferred ranges separately from the rest of the range.
I am sorry, that explanation did not really help me understand. As far
as I understand, CommitSpillsAtDefinition runs after the actual
allocation, so I do not see how this can setup the stage for register
allocation. Could you explain? Where exactly is the place that adds the
spilling move for deferred blocks with calls?
Or are you saying that the pre-processing phase inserts live ranges for
the deferred blocks so that the register allocator can spill those
ranges (and since those ranges begin in deferred blocks, they would get
the right spill)? I cannot see how this would work either because the
pre-processing seems to only create child ranges, so they would not
really get their own definitions.
https://codereview.chromium.org/1271703002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
