[llvm-dev] Problems with subreg-liveness and Greedy RA

Quentin Colombet via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 22 12:20:59 PDT 2021

> On Jun 21, 2021, at 10:05 AM, Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> I am having a really difficult time with subregister related issues when I turn
> on subregister liveness tracking.
> Before RA:
> 79760B    %2216:vsrc = LXVDSX %5551:g8rc_and_g8rc_nox0, %2215:g8rc :: (load 8 from %ir.scevgep1857.cast, !alias.scope !92, !noalias !93)
> 79872B    %2225:vsrprc = LXVP 352, %661:g8rc_and_g8rc_nox0
> 84328B    %5540:vsrc = contract nofpexcept XVMADDADP %5540:vsrc(tied-def 0), %2225.sub_vsx0:vsrprc, %2216:vsrc, implicit $rm
> After RA (greedy):
> 79744B    %2214:vsrc = LXVDSX %5551:g8rc_and_g8rc_nox0, %6477:g8rc :: (load 8 from %ir.scevgep1860.cast, !alias.scope !92, !noalias !93)
> 79872B    %7503:vsrprc = LXVP 352, %661:g8rc_and_g8rc_nox0
> 80248B    %7527:vsrprc = COPY %7503:vsrprc
> 80988B    undef %7526.sub_64:vsrprc = COPY %7527.sub_64:vsrprc
> 84324B    undef %7501.sub_64:vsrprc = COPY %7526.sub_64:vsrprc
> 84328B    %5546:vsrc = contract nofpexcept XVMADDADP %5546:vsrc(tied-def 0), %7501.sub_vsx0:vsrprc, %2214:vsrc, implicit $rm
> Subregister definitions for PPC:
> def sub_64 : SubRegIndex<64>;
> def sub_vsx0 : SubRegIndex<128>;
> def sub_vsx1 : SubRegIndex<128, 128>;
> def sub_pair0 : SubRegIndex<256>;
> def sub_pair1 : SubRegIndex<256, 256>;
> So the instruction at 84328B uses the full register %2216 and the high order
> 128 bits of (256-bit) register %2225. However, the register allocator splits
> the live range and introduces a copy of the high order 64 bits of that 256-bit
> register, then another copy of that copy and rewrites the use in instruction
> 84328B to that copy. The copy is marked undef so the register allocator
> assigns just some random register to the use of that copy in 84328B.
> Or maybe I am completely misinterpreting the meaning of the debug dumps
> from the register allocator.
> This appears to be related to lane masks and dead lane detection although
> I don't see dead lane detection marking anything unexpected as undef (seems
> to just be INSERT_SUBREG and PHI).

Are the copies added by dead lane detection or by live-range splitting?

The undef flag on the definition of %7501 is suspicious and depending on how you look at it, so is the one on %7526. Essentially, we are losing the full copy in this chain of copies and I wonder what is at fault here.

Could you share the debug output of regalloc?

> If anyone has suggestions on what might be the issue and/or how to go about figuring this out and fixing it, I would really appreciate it.
> Nemanja
> _______________________________________________
> 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/20210622/2f5ab3c0/attachment.html>

More information about the llvm-dev mailing list