[llvm-dev] Inline Spiller spilling multiple duplicate copies

[Quentin Colombet via llvm-dev]

Hi Ryan,

Could you attach the test case to reproduce?

I’d like to see the full regalloc output among other things.

Thanks,
-Quentin 
> On Mar 14, 2016, at 9:31 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> 
> Quentin,
> 
>   Thanks for responding.
> 
>   Yes, you need virtual regs for SSA form.
> 
>   What I'm seeing as far as output are multiples of the exact same instruction (ie multiple storeRegToStack instructions). When I say 'exact same instruction', I mean literally, something like:
> 
> mov %r0, 0[%sp]
> mov %r0, 0[%sp]
> mov %r0, 0[%sp]
> mov %r0, 0[%sp]
> 
> and so on and so on. These instructions are redundant and need to be removed/eliminated but they are making it all the way to the asm.
> 
> Looking at InlineSpiller.cpp in spillAroundUses it's iterating over instructions using "Reg".
> 
> For example, adding statements to the code I get the following sequence when iterating over the loop in spillAroundUses I mentioned above:
> 
> First iteration of loop:
> MI: %vreg627<def> = COPY %vreg628; PTRRegs:%vreg627,%vreg628
> Storing PTRRegs 2147484276
> 
> Second iteration of loop:
> MI: %vreg627<def> = COPY %vreg628; PTRRegs:%vreg627,%vreg628
> Storing PTRRegs 2147484276
> 
> Third iteration of loop:
> MI: %vreg628<def> = COPY %vreg627; PTRRegs:%vreg628,%vreg627
> 
> Given this, I will get TWO 'mov' instructions In the same that do the same thing (ie, there are two "Storing PTRRegs above", like:
> 
> mov %b1, 0[%sp]
> mov %b1, 0[%sp]
> 
> The code is calling hoistSpill which is calling storeRegToStack and then marking the MI Operand as dead but never checking if it's dead in subsequent iterations. Also, the MRI.reg_bundle seem to be made of copies, so the 'dead' doesn't carry over between iterations anyways.
> 
> So I'm not sure if:
> 1) The dead check should be added in the loop.
> 2) The multiple COPY instructions should not have been generated in the first place.
> 
> Thank you, your time is appreciated. If this doesn't make sense I can try and elaborate.
> 
> 
> On Mon, Mar 14, 2016 at 12:17 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
> Hi Ryan,
> 
> 
>> On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> I looked at this again and it appears that while spillAroundUses sets the register as 'dead', there is no checking to see if it's dead in subsequent iterations of the bundle loop.
>> 
>> Is this intentional?
>> 
>> On Mon, Mar 7, 2016 at 3:28 PM, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
>> Looks like spillAroundUses is spilling multiple duplicate copies to the stack, for example, with some regs we get 1 storeRegToStack call, for others we get multiple (2-6+) and then these instructions are never eliminated.
>> 
>> Looking at spillAroundUses it looks like multiple duplicate COPYs are being generated, why? One for each use?
> 
> We need a new virtual register for each use to have an independent coloring for each of them.
> If it is not what you are seeing, I think I would need more information to help you.
> For instance, the machine representation you have before and after spilling and why this is not appropriate.
> 
> Cheers,
> -Quentin
> 
>> 
>> The reg_bundle holds these multiple copies so that we are iterating over the same exact COPY instructions multiple times, even though each one hits the same spot in the function:
>> 
>> if (hoistSpill(OldLI, MI)) {
>>      MI->getOperand(0).setIsDead();
>>      DeadDefs.push_back(MI);
>>      continue;
>> }
>> 
>> Even when I add a check:
>> 
>> if (MI->getOperand(0)->isDead())
>>     continue;
>> 
>> This never checks to true, on the second, third, fourth, etc duplicate.
>> 
>> Not sure what I'm missing? Can someone give me a brief description of why these multiple COPYs are being written out (storeRegToStack is being called)?
>> 
>> Thanks.
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160314/670c74dd/attachment-0001.html>