<div dir="ltr">Martin:<div><br></div><div>It sounds like you are doing is more akin to shuffle selection than fusion and therefore it's a better fit for instruction selection than DAGCombining. Try movign it to <Target>ISelDAGToDAG's Select (or potentially PreprocessISelDAG). </div><div><br></div><div>Th</div><div><br></div><div>-Nirav</div><div><br></div><div><br></div></div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 6, 2018 at 4:05 PM Martin J. O'Riordan <<a href="mailto:MartinO@theheart.ie">MartinO@theheart.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-IE" link="blue" vlink="purple"><div class="m_8295949684301924702WordSection1"><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">We discovered what is happening.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">SDAGCombiner essentially looks at various combinations of nodes to do with vectors, and when it can, it creates a vector shuffle.  The problem is, that our vector shuffle lowering builds new trees with vector element, or vector sub-vector insert sequences.  The generic DAGCombiner, reconstructs these into a new shuffle, and so the loop continues - we reduce it, and DAGCombiner re-abstracts it.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">Our shuffle lowering produces (produced) very optimal code sequences for our target, and has not been changed significantly since LLVM v3.4; but changes between v5.0 and v6.0 have introduced this DAG reduction dependency loop.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">Is there any advice to Out-of-Tree implementations about how to re-write their lowering code for shuffle so as to avoid this kind of infinite dependency coupling?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">Thanks,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634">    MartinO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:"Book Antiqua",serif;color:#943634"><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Nirav Davé [mailto:<a href="mailto:niravd@google.com" target="_blank">niravd@google.com</a>] <br><b>Sent:</b> 01 March 2018 20:45<br><b>To:</b> <a href="mailto:MartinO@theheart.ie" target="_blank">MartinO@theheart.ie</a><br><b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b> Re: [llvm-dev] Heap Exhaustion during 'DAGCombiner::Run'<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Martin:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I suspect this is an issue with post-DAG legalization store merging in the DAGCombiner. If you have a custom lowered type the DAGCombiner may end up merging a set of stores and immediately splitting them up in legalization. You should be able to disable this pass universally by overriding mergeStoresAfterLegalization() or conditionally for cases that shouldn't match with canMergeStoresTo. <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">You should able able to verify by finding the loop of nodes considered with "-debug" on.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-Nirav<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><div><p class="MsoNormal">On Sun, Feb 25, 2018 at 9:36 AM Martin J. O'Riordan via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">Hi LLVM-Devs,<br><br>I am in the process of updating our out-of-tree implementation from v5.0 to<br>v6.0 RC3, and while it builds and mostly runs, I am having trouble with a<br>small number of tests where the 'WorklistMap' in 'DAGCombiner::Run' never<br>becomes empty.  This is resulting in a runaway state of continuous heap<br>allocation until the process exhausts all system memory.<br><br>But I can't get a handle on why it is doing this, and it is not obvious to<br>me that the changes between v5.0 and v6.0 RC3 invalidate our implementation<br>in a way that might cause this.  The only time I see our code entered is<br>when lowering is called for vector element insert by 'LegalizeOp'.  Does<br>anybody have an advice on how I should approach debugging this?<br><br>Thanks,<br><br>        MartinO<br><br><br>_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p></blockquote></div></div></div></blockquote></div>