<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;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{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'>Sorry for long trip time on this. The issue I was seeing when we defer simplifying unconditional branches to later passes in backend was due to a heuristic in CGP::</span> <span style='color:windowtext'>isMergingEmptyBlockProfitable where we assumed cost of branch is same as cost of copy. However, if the destination block is almost empty latch block, then we can hoist the jump through the backedge, so it is profitable to eliminate the branch. I have posted a patch for review here: <a href="https://reviews.llvm.org/D35411">https://reviews.llvm.org/D35411</a>.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Please take a look and let me know your comments/suggestions.<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Balaram<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><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'> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>Balaram Makam via llvm-dev<br><b>Sent:</b> Friday, June 30, 2017 3:11 PM<br><b>To:</b> 'Friedman, Eli' <efriedma@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><p class=MsoNormal><span style='color:windowtext'>I will try to reduce a test case for the regression I found and will update.<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>Balaram<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><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 [</span><a href="mailto:efriedma@codeaurora.org">mailto:efriedma@codeaurora.org</a><span style='color:windowtext'>] <br><b>Sent:</b> Friday, June 30, 2017 2:54 PM<br><b>To:</b> Balaram Makam <</span><a href="mailto:bmakam@codeaurora.org">bmakam@codeaurora.org</a><span style='color:windowtext'>>; </span><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><span style='color:windowtext'><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 11:38 AM, Balaram Makam 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><span style='color:windowtext'>Thanks Eli,</span><o:p></o:p></p><p class=MsoNormal><span style='color:windowtext'> </span><o:p></o:p></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.</span><o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br>There isn't really any reason to collapse preheaders anyway; LoopSimplify will recreate them, and they don't really block other optimizations as far as I know.<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='color:windowtext'>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.</span><o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br>Well, not that expensive to calculate if you cache it, but probably tricky to keep the cache up-to-date, yes.<br><br><o:p></o:p></span></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span style='color:windowtext'>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?</span><o:p></o:p></p></blockquote><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:12.0pt;font-family:"Times New Roman",serif'><br>I'm not sure I follow the issue here. Could you give an example?</span><span style='font-size:10.0pt;font-family:"Courier New"'><o:p></o:p></span></p></div></body></html>