<html><body><p><font size="2">Hi,</font><br><br><font size="2">I think the issue is not specific to LICM and can be observed with other transforms like the SCEV expander. This was brought up in one of the Loop Optimization WG calls before </font><a href="http://lists.llvm.org/pipermail/llvm-dev/2019-September/135058.html"><font size="2">http://lists.llvm.org/pipermail/llvm-dev/2019-September/135058.html</font></a><font size="2"> as well. The general feedback at the time was that it would be better to deal with the issue in the back-end perhaps through rematerialization of the hoisted instructions in RA using LiveRangeEdit. </font><br><br><font size="2">I don't have much in-depth knowledge in this area, but the blocker issue at that time appeared to be that the register allocator could only rematerialize single instructions and we needed groups of instructions to be moved/copied. Does anyone know if any progress is under way in that area?</font><br><br><font size="2">Bardia Mahjour<br>Compiler Optimizations<br>IBM Toronto Software Lab<br></font><br><br><img width="16" height="16" src="cid:1__=8FBB0CA4DFC6816F8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Sjoerd Meijer via llvm-dev ---2020/12/07 08:25:47 AM---Hello, I would like to restrict LICM in the nu"><font size="2" color="#424282">Sjoerd Meijer via llvm-dev ---2020/12/07 08:25:47 AM---Hello, I would like to restrict LICM in the number of memory operations it hoists out of a loop. Bli</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Sjoerd Meijer via llvm-dev <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">"llvm-dev@lists.llvm.org" <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">2020/12/07 08:25 AM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[EXTERNAL] [llvm-dev] loop invariant code hoisting</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">"llvm-dev" <llvm-dev-bounces@lists.llvm.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="1" color="#FFFFFF">Hello, I would like to restrict LICM in the number of memory operations...                                                                                                                                                                                      </font><table width="100%" border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="100%" bgcolor="#9CA3A7" valign="middle"><div align="center"><table class="pfptMainWrapper" border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="902"><div align="center"><table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td class="pfptTableColumnLeft" width="453" bgcolor="#9CA3A7"><div align="center"><table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="228" valign="middle"><b><font size="4" face="Helvetica">This Message Is From an External Sender</font></b></td></tr>
<tr valign="top"><td width="228" valign="middle"><font size="2" face="Helvetica">This message came from outside your organization.</font></td></tr></table></div></td></tr></table></div></td></tr></table></div></td></tr></table><font face="Arial">Hello,</font><br><br><font face="Arial">I would like to restrict LICM in the number of memory operations it hoists out of a loop. Blindly hoisting out all instructions out could result in a lot of spilling/reloading, which is what I'd like to avoid. We see this for example on (inner)loops with small constant bounds that are unrolled. I am drafting something in </font><a href="https://reviews.llvm.org/D92488"><u><font color="#0000FF" face="Arial">https://reviews.llvm.org/D92488</font></u></a><font face="Arial">, which contains a reduced version of my motivating example.</font><br><font face="Arial">It was brought to my attention that LICM might not have any restrictions by design because hoisting out all instructions could be some sort of canonical form that other passes depend on, so sinking back defs closer to their user(s) might be a back-end problem. I was wondering if there are any opinions on this.</font><br><br><font face="Arial">Cheers,</font><br><font face="Arial">Sjoerd.</font><tt><font size="2">_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br></font></tt><tt><font size="2"><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></font></tt><tt><font size="2"> <br></font></tt><br><br><BR>
</body></html>