[llvm-dev] Inline Spiller spilling multiple duplicate copies

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 14 09:17:12 PDT 2016


Hi Ryan,


> On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <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
> 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/b89c21b2/attachment.html>


More information about the llvm-dev mailing list