<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:windowtext'>Thanks Eli,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>I was looking at this code which keeps track of loop headers but is checking if the destination of branch is a loop header sufficient? This prevents merging empty preheaders into the loop headers as well. Is that reasonable approach or do we need to skip only if the original unconditional branch was a backedge and folding this branch might result in additional backedges? I made a quick hack to find the function backedges and skip simplifycfg to merge the latch block into the loop header when it results in an additional backedge. Although it solves my purpose I am not sure if this the right approach, as finding the backedges looks expensive. I also found a regression with this patch where a huge switch statement with multiple empty blocks have been skipped from merging resulting in bad code. Instead, should loopsimplify try to unify multiple exit blocks and collapse multiple backedges whenever possible instead of splitting it out into a nested loop?<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:windowtext'>-Balaram<o:p></o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='color:windowtext'>From:</span></b><span style='color:windowtext'> Friedman, Eli [mailto:efriedma@codeaurora.org] <br><b>Sent:</b> Friday, June 30, 2017 1:59 PM<br><b>To:</b> Balaram Makam <bmakam@codeaurora.org>; llvm-dev@lists.llvm.org<br><b>Subject:</b> Re: [llvm-dev] LoopSimplify pass prevents loop unrolling<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 6/30/2017 7:48 AM, Balaram Makam via llvm-dev wrote:<span style='font-size:12.0pt'><o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Edit. Predecessor -> successor.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>] <b>On Behalf Of </b>Balaram Makam via llvm-dev<br><b>Sent:</b> Friday, June 30, 2017 10:47 AM<br><b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br><b>Subject:</b> [llvm-dev] LoopSimplify pass prevents loop unrolling<o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Hi All,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>In the attached test case there, is an unnested loop with 2 iterations. The loop latch block is terminated by an unconditional branch, so simplifycfg folds the almost empty latch block into its <b>successor</b> which is the loop header. This results in an additional backedge in the CFG, so when LoopRotate pass is called it canonicalizes the loop into a nested loop. However, now the loop trip count is unpredictable as the BackedgeTakenCount for the outer loop is not loop invariant. As a result the loop cannot be unrolled. Is this the intended canonicalization for this loop or is the loopsimplify canonicalizing incorrectly? Should simplifycfg skip folding the latch block into the loop header if this results in additional backedges and let the empty blocks be folded during CGP? More details in <a href="https://bugs.llvm.org/show_bug.cgi?id=33605">https://bugs.llvm.org/show_bug.cgi?id=33605</a>.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p></blockquote><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br>We have code that's supposed to prevent this from happening; see </span><a href="https://reviews.llvm.org/rL264697"><span style='font-size:12.0pt;font-family:"Times New Roman",serif'>https://reviews.llvm.org/rL264697</span></a><span style='font-size:12.0pt;font-family:"Times New Roman",serif'> . Maybe it also needs to check whether the destination of the branch is a loop header?<br><br>-Eli <o:p></o:p></span></p><pre>-- <o:p></o:p></pre><pre>Employee of Qualcomm Innovation Center, Inc.<o:p></o:p></pre><pre>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<o:p></o:p></pre></div></body></html>