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

Jakob Stoklund Olesen stoklund at 2pi.dk
Mon Apr 1 11:43:42 PDT 2013


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.

/jakob




More information about the llvm-commits mailing list