[llvm] r269969 - When looking for a spill slot in reg scavenger, find one that matches RC

[Jordy Potman via llvm-commits]

Yes, this fix works for me.

Jordy

On Fri, May 20, 2016 at 3:12 PM, Krzysztof Parzyszek <
kparzysz at codeaurora.org> wrote:

> Hi Jordy,
>
> Does this fix work for you?
>
>   unsigned SI = Scavenged.size(), Diff = UINT_MAX;
> + int FIB = MFI.getObjectIndexBegin(), FIE = MFI.getObjectIndexEnd();
>   for (unsigned I = 0; I < Scavenged.size(); ++I) {
>     if (Scavenged[I].Reg != 0)
>       continue;
>     // Verify that this slot is valid for this register.
>     int FI = Scavenged[I].FrameIndex;
> +   if (FI < FIB || FI >= FIE)
> +     continue;
>     unsigned S = MFI.getObjectSize(FI);
>     unsigned A = MFI.getObjectAlignment(FI);
>
> -Krzysztof
>
>
>
> On 5/20/2016 7:04 AM, Jordy Potman wrote:
>
>> Hi Krzysztof,
>>
>> I'm seeing an "Invalid Object Idx" assert in the call to
>> MFI.getObjectSize(FI) in the code below on my out of tree target after
>> this commit.
>>
>>     +    // Verify that this slot is valid for this register.
>>     +    int FI = Scavenged[I].FrameIndex;
>>     +    unsigned S = MFI.getObjectSize(FI);
>>     +    unsigned A = MFI.getObjectAlignment(FI);
>>     +    if (NeedSize > S || NeedAlign > A)
>>     +      continue;
>>
>>
>> The reason for this is that the Scavenged vector may contain a
>> ScavengedInfo structure with a FrameIndex of -1 after the first call of
>> scavengeRegister on targets where there is no spill slot but the target
>> knows how to save/restore the register (using
>> TRI->saveScavengerRegister). This ScavengedInfo structure with a
>> FrameIndex of -1 is added to the Scavenged vector by the code on lines
>> 425-429 in the first call of scavengeRegister.
>>
>> I have fixed this in my tree by adding
>>
>> if (FI < 0)
>>   continue;
>>
>> before the the call to MFI.getObjectSize(FI) in the code above, see the
>> attached patch, but there may be a cleaner/better solution.
>>
>> Jordy
>>
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160520/0443bbf3/attachment.html>