Sorry - let me try to be more detailed. Here's the larger picture: First, PreprocessLiveRanges splits ranges at the beginning and end of deferred blocks. No moves (including spill/fill) are added at this point.
Register allocation then decides on what gets allocated or spilled, so the sub-segments in the deferred blocks get appropriately spilled. That still doesn't in itself add any moves just yet. Skip a couple of phases to CommitAssignmentPhase. Here, we normally spill at definition, however, we first try to TryCommitSpillInDeferredBlock. If that succeeds, we don't spill at definition. That (TryCommitSpillInDeferredBlock) doesn't just yet spill (==add moves) at the child definitions either (it does insert some moves for cases that need operands on the stack without spilling, though, but we can glaze over this right now) We now get to ConnectLiveRanges and then ResolveControlFlow. Together, they insert moves of the form Operand(child_(k+1)) = Operand(child_k), where child_(k+1) and child_k are successive children of a range, and Operand(...) is their assigned operand - be it a register or a slot. ConnectLiveRanges does this when the control flow may be trivially resolved (essentially, when CanEagerlyResolveControlFlow is true), while ResolveControlFlow does it for the non-trivial control flow case. The latter is also where we get the equivalent of the lowering of a phi instruction for scenarios where sub-ranges were assigned different operands on what turns out to be different control flow branches - see the logic in ResolveControlFlow (the one with 4 parameters). So these two last phases here discussed is where spilling at definition for our scenario happens - see the changes I made in both with the use of IsSpilledOnlyInDeferredBlocks. Before, a range was spilled at definition, so we didn't need to connect a spilled range to its predecessor child range. Now we do, if it is IsSpilledOnlyInDeferredBlocks. We leverage an existing mechanism with relatively minimal changes. This change means that each deferred block of a IsSpilledOnlyInDeferredBlocks range is penalized by spills and fills, which may be redundant, but given these are deferred blocks, we are fine with that (it's the intention) - so we need to tell the optimizer to not try to optimize these away. Hope this helps - let me know if any of this should make into comments (probably, yes :)) On Wed, Aug 5, 2015 at 7:04 AM <[email protected]> wrote: > > > 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 > <https://codereview.chromium.org/1271703002/diff/60001/src/compiler/register-allocator.cc#newcode392src/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.
