[llvm] r178058 - Update PEI's virtual-register-based scavenging to support multiple simultaneous mappings

[Hal Finkel]

----- Original Message -----
> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Pranav Bhandarkar" <pranavb at codeaurora.org>, "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Monday, April 1, 2013 1:43:42 PM
> Subject: Re: [llvm] r178058 - Update PEI's virtual-register-based scavenging to support multiple simultaneous
> mappings
> 
> 
> On Apr 1, 2013, at 1:42 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > ----- Original Message -----
> >> From: "Pranav Bhandarkar" <pranavb at codeaurora.org>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: llvm-commits at cs.uiuc.edu
> >> Sent: Sunday, March 31, 2013 7:55:17 PM
> >> Subject: Re: [llvm] r178058 - Update PEI's virtual-register-based
> >> scavenging to support multiple simultaneous
> >> mappings
> >> 
> >> Hi Hal,
> >> 
> >>       }
> >> -      RS->forward(I);
> >> -      ++I;
> >> +
> >> +      // If the scavenger needed to use one of its spill slots,
> >> the
> >> +      // spill code will have been inserted in between I and J.
> >> This
> >> is a
> >> +      // problem because we need the spill code before I: Move I
> >> to
> >> just
> >> +      // prior to J.
> >> +      if (I != llvm::prior(J)) {
> >> +        BB->splice(J, BB, I++);
> >> +        RS->skipTo(I == BB->begin() ? NULL : llvm::prior(I));
> >> +      } else
> >> +        ++I;
> >> 
> >> I think there is a problem with the above. Suppose RS had to use
> >> one
> >> of
> >> its spill slots, then the new spill instruction, say A, is now
> >> between I
> >> and J and we move I to just after A. So, now, prior(I) is A and we
> >> begin
> >> processing again from A. However, if I, which RS has already
> >> processed
> >> was killing a register, then that register, say Rx is now
> >> available.
> >> After A, when we process I again the RS asserts because a use of
> >> Rx
> >> is
> >> found when Rx is available (seemingly, a use without a def).
> > 
> > Pranav,
> > 
> > You're right! We'll need to 'unprocess' I if we're going to process
> > it again later (or at least we need to remark as used all
> > registers killed by I). Can you please bugpoint a reduced test
> > case for me?
> 
> I wonder if the scavenger position could be updated on demand?
> 
> Most basic blocks shouldn't require the scavenger's services, but we
> still meticulously RS->forward() our way through every basic block
> one instruction at a time. The liveness computations aren't free,
> and we could skip a lot of them that way.

An easy thing to do would be not to process blocks which don't define any virtual registers. Is there a quick way to query the block for this?

Thanks again,
Hal

> 
> /jakob
> 
>