<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=utf-8">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:2.0cm 42.5pt 2.0cm 3.0cm;}
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 lang="RU" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Hi Daniel,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I believe that using cache here was a wrong idea initially. It was done in assumption that we meet the same values throughout
 recursions, which was true for the particular test when the patch with was developed, but actually there is no reason why it should be true in general. If you look into the test of PR33431, its compilation takes few minutes either with or without cache. Cache
 is just useless there, and as side effect it consumes 800M of memory.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">So the root problem is that the recursion here can be deep, leading to long compilation or stack overflows, and massive
 memory consumption by cache is one of side effects of that. My intention was to deal with the root problem, not make a workaround for workaround.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">-- Max<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></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"> Daniel Berlin [mailto:dberlin@dberlin.org]
<br>
<b>Sent:</b> Thursday, June 22, 2017 8:52 AM<br>
<b>To:</b> reviews+D34273+public+1b835f147de217a1@reviews.llvm.org; Max Kazantsev via Phabricator <reviews@reviews.llvm.org><br>
<b>Cc:</b> Maxim Kazantsev <max.kazantsev@azul.com>; Wei Mi <wmi@google.com>; Sanjoy Das <sanjoy@playingwithpointers.com>; Philip Reames <listmail@philipreames.com>; Junbum Lim <junbuml@codeaurora.org>; llvm-commits <llvm-commits@lists.llvm.org><br>
<b>Subject:</b> Re: [PATCH] D34273: [SCEV] Use depth limit instead of local cache for SExt and ZExt<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">To control the size of the cache, why not just LRU it instead?<br>
Limiting recursion depth seems like a really big hammer to use here.<o:p></o:p></p>
<div>
<p class="MsoNormal">Is there really no better way?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Jun 16, 2017 at 5:02 AM, Max Kazantsev via Phabricator via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<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" style="margin-bottom:12.0pt">mkazantsev created this revision.<br>
Herald added a subscriber: mzolotukhin.<br>
<br>
In <a href="https://reviews.llvm.org/rL300494" target="_blank">https://reviews.llvm.org/rL300494</a> there was an attempt to deal with excessive compile time on<br>
invocations of getSign/ZeroExtExpr using local caching. This approach only<br>
helps if we request the same SCEV multiple times throughout recursion. But<br>
in the bug PR33431 we see a case where we request different values all the time,<br>
so caching does not help and the size of the cache grows enormously.<br>
<br>
In this patch we remove the local cache for this methods and add the recursion<br>
depth limit instead, as we do for arithmetics. This gives us a guarantee that the<br>
invocation sequence is limited and reasonably short.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D34273" target="_blank">https://reviews.llvm.org/D34273</a><br>
<br>
Files:<br>
  include/llvm/Analysis/ScalarEvolution.h<br>
  lib/Analysis/ScalarEvolution.cpp<br>
  lib/Transforms/Utils/SimplifyIndVar.cpp<br>
  test/Analysis/ScalarEvolution/limit-depth.ll<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>