Nemanja Ivanovic via llvm-dev
2021-Jun-21 17:05 UTC
[llvm-dev] Problems with subreg-liveness and Greedy RA
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). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/c558da52/attachment.html>
Quentin Colombet via llvm-dev
2021-Jun-22 19:20 UTC
[llvm-dev] Problems with subreg-liveness and Greedy RA
> 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>