[llvm-dev] RegAlloc Q: spill when implicit-def physreg is also the output reg of instruction

[Quentin Colombet via llvm-dev]

Hi Kevin,

That sounds like a bug :).

When is the implicit-def added?

What I am thinking is if it gets added after we computed the live intervals, then we may miss it is there.

Could you file a public report?

Thanks,
-Quentin

> On May 6, 2019, at 3:13 PM, Kevin Choi via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi LLVM,
> 
> I ran into a case where RegAlloc would insert a spill across instruction that had same register for output operand and implicit-def. The effect this had was that spill code would immediately overwrite the output result. Is this the expected result of setting up MyInst this way? In other words, does RegAlloc know to not insert spill in case it sees that output reg is same as one of implicit-def?
> 
> If this is intended (always spilling live regs across implicit-def inst?), I am puzzled on how to use MyInst that has variable output reg with static implicit-defs. Any tips would be greatly appreciated.
> 
> Reduced Example:
> 
> Before RegAlloc:
> %1:reg = COPY ...;
> %2:reg = MyInst %1:reg, ..., implicit-def dead $p1, ...;
> %3:reg = Use %2:reg
> 
> RegAlloc:
> >> %2:reg = MyInst %1:reg, ..., implicit-def dead $p1, ...;
> Regs: $p1=%1
> Killing last use: %1:reg
> Assigning %2 to $p1
> Spilling %2 in $p1 to stack slot #2  <-- suspicious if this is inserting spill, unaware of output reg being same
> << $p1 =MyInst killed $p1, ..., implicit-def dead $p1, ...;
> After RegAlloc:
> $p1 = COPY ...;
> Store $p1 %stack.2;
> $p1 =MyInst killed $p1, ..., implicit-def dead $p1, ...;
> $p1 = Load %stack.2;
> $p2 = Use $p1, ...;
> 
> 
> 
> Best Regards,
> 
> Kevin
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190507/b0cc14f1/attachment.html>