<div dir="ltr"><div>Sorry, it would appear that the dev list stripped my attachment. I have reduced the file using bugpoint and produced the output from that. Attaching it here.</div><div><br></div><div>Nemanja<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 23, 2021 at 2:23 PM Nemanja Ivanovic <<a href="mailto:nemanja.i.ibm@gmail.com">nemanja.i.ibm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thank you so much for taking the time to answer Quentin.</div><div><br></div><div>The bad copies are definitely added by live range splitting. The issue seems to be the LaneBitmasks for the various subregisters. Honestly, I don't really know what the bits of LaneBitmask produced by TblGen are meant to mean, but I can't make any sense of them. And those seem to lead the register allocator astray.</div><div>Here are the LaneBitmasks from the register include file:<br></div><div><span style="font-family:monospace">static const LaneBitmask SubRegIndexLaneMaskTable[] = {<br>  LaneBitmask::getAll(),<br>  LaneBitmask(0x0000000000000001), // sub_32<br>  LaneBitmask(0x0000000000000002), // sub_64<br>  LaneBitmask(0x0000000000000004), // sub_eq<br>  LaneBitmask(0x0000000000000001), // sub_gp8_x0<br>  LaneBitmask(0x0000000000000200), // sub_gp8_x1<br>  LaneBitmask(0x0000000000000008), // sub_gt<br>  LaneBitmask(0x0000000000000010), // sub_lt<br>  LaneBitmask(0x0000000000000042), // sub_pair0<br>  LaneBitmask(0x0000000000000180), // sub_pair1<br>  LaneBitmask(0x0000000000000020), // sub_un<br>  LaneBitmask(0x0000000000000002), // sub_vsx0<br>  LaneBitmask(0x0000000000000040), // sub_vsx1<br>  LaneBitmask(0x0000000000000040), // sub_vsx1_then_sub_64<br>  LaneBitmask(0x0000000000000080), // sub_pair1_then_sub_64<br>  LaneBitmask(0x0000000000000080), // sub_pair1_then_sub_vsx0<br>  LaneBitmask(0x0000000000000100), // sub_pair1_then_sub_vsx1<br>  LaneBitmask(0x0000000000000100), // sub_pair1_then_sub_vsx1_then_sub_64<br>  LaneBitmask(0x0000000000000200), // sub_gp8_x1_then_sub_32<br> };</span></div><div><br></div><div>For example, what does it mean that the mask for <span style="font-family:monospace">sub_64</span> and <span style="font-family:monospace">sub_vsx0</span> are the same? The two subregisters certainly do not represent the same lanes in their respective registers. The <span style="font-family:monospace">sub_vsx0</span> subregister is the first VSX register in a VSX register pair. And each of the two subregisters of a VSX register pair (<span style="font-family:monospace">sub_vsx0</span>, <span style="font-family:monospace">sub_vsx1</span>) have their own scalar subregister (<span style="font-family:monospace">sub_64</span>).<br></div><div><br></div><div>I have also attached the output of RA, but it is huge :(</div><div>It is the result of specifying options <span style="font-family:monospace">-debug-only=regalloc -print-before=greedy -print-after=greedy</span> on the command line.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 22, 2021 at 3:21 PM Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Jun 21, 2021, at 10:05 AM, Nemanja Ivanovic via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">I am having a really difficult time with subregister related issues when I turn<br>on subregister liveness tracking.<br><br>Before RA:<br><span style="font-family:monospace">79760B    %2216:vsrc = LXVDSX %5551:g8rc_and_g8rc_nox0, %2215:g8rc :: (load 8 from %ir.scevgep1857.cast, !alias.scope !92, !noalias !93)<br>79872B    %2225:vsrprc = LXVP 352, %661:g8rc_and_g8rc_nox0<br>84328B    %5540:vsrc = contract nofpexcept XVMADDADP %5540:vsrc(tied-def 0), %2225.sub_vsx0:vsrprc, %2216:vsrc, implicit $rm<br></span><br>After RA (greedy):<br><span style="font-family:monospace">79744B    %2214:vsrc = LXVDSX %5551:g8rc_and_g8rc_nox0, %6477:g8rc :: (load 8 from %ir.scevgep1860.cast, !alias.scope !92, !noalias !93)<br>79872B    %7503:vsrprc = LXVP 352, %661:g8rc_and_g8rc_nox0<br>80248B    %7527:vsrprc = COPY %7503:vsrprc<br>80988B    undef %7526.sub_64:vsrprc = COPY %7527.sub_64:vsrprc<br>84324B    undef %7501.sub_64:vsrprc = COPY %7526.sub_64:vsrprc<br>84328B    %5546:vsrc = contract nofpexcept XVMADDADP %5546:vsrc(tied-def 0), %7501.sub_vsx0:vsrprc, %2214:vsrc, implicit $rm<br></span><br>Subregister definitions for PPC:<br><span style="font-family:monospace">def sub_64 : SubRegIndex<64>;<br>def sub_vsx0 : SubRegIndex<128>;<br>def sub_vsx1 : SubRegIndex<128, 128>;<br>def sub_pair0 : SubRegIndex<256>;<br>def sub_pair1 : SubRegIndex<256, 256>;<br></span><br>So the instruction at 84328B uses the full register %2216 and the high order<br>128 bits of (256-bit) register %2225. However, the register allocator splits<br>the live range and introduces a copy of the high order 64 bits of that 256-bit<br>register, then another copy of that copy and rewrites the use in instruction<br>84328B to that copy. The copy is marked undef so the register allocator<br>assigns just some random register to the use of that copy in 84328B.<br><br>Or maybe I am completely misinterpreting the meaning of the debug dumps<br>from the register allocator.<br><br>This appears to be related to lane masks and dead lane detection although<br>I don't see dead lane detection marking anything unexpected as undef (seems<br><div>to just be INSERT_SUBREG and PHI).</div></div></div></blockquote><div><br></div><div>Are the copies added by dead lane detection or by live-range splitting?</div><div><br></div><div>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.</div><div><br></div>Could you share the debug output of regalloc?</div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>Nemanja<br></div></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></blockquote></div>
</blockquote></div>