[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