<div dir="ltr">Hi Hal,<div><br></div><div>Yes, the "internal" caches AA would be valid as long as the IR is not mutated. Are you suggesting keeping them? It's possible, but it will be very tricky to ensure they are cleared at the right times and they will likely be prone to adding hidden bugs.</div><div>I don't have strong indications currently that keeping such information would be useful by other users, other than MemorySSA, and only at build time, so I'd rather not sign up for updating/invalidating such internal caches.</div><div><br></div><div>MemorySSA itself can be viewed as a cache, but you can view it as storing different information than what AA computes internally. e.g. MemorySSA will not remember "is this pointer captured". But, while building MemorySSA, there are a lot of queries asking if a pointer is captured.</div><div>With MemorySSA we know we benefit from reusing the info it stores, so having passes update it makes sense.</div><div><br></div><div>Does that makes sense, or did I misunderstand your question?</div><div><br></div><div>Alina</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 4, 2019 at 5:23 PM Finkel, Hal J. <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div bgcolor="#FFFFFF">
<p><br>
</p>
<div class="gmail-m_4068406929172371701moz-cite-prefix">On 3/4/19 7:08 PM, Alina Sbirlea via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">TL;DR: I'm looking to have AliasAnalysis passes have the ability keep a temporary cache when no transformations are performed.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">
<div><span>I'm interested to first and foremost clarify what is the
 best way to even start such an infrastructure change, such that it is not abused (or even available) by other passes. We certainly don't want to keep arbitrary caches in all passes. </span></div>
<div><span>Would making this a feature used exclusively by MemorySSA
 make sense?</span></div>
<div><span>Only from other Analysis? </span></div>
<div><br>
</div>
<div>The usecases I have stem from BasicAA and TBAA being used to build MemorySSA. <br>
</div>
<div>MemorySSA is essentially a cache itself, and we're building it with a stateless tool.</div>
<div>We know that while building MemorySSA, there are no changes in the program, and yet, there is info that is computed again and again.</div>
<div><br>
</div>
<div>One example is this patch: <a href="https://reviews.llvm.org/D57627" target="_blank">D57627</a>. The patch adds a cache for <span>PointerMayBeCaptured,
 which is cleared after every alias() call, in order to keep BasicAA stateless. In the example given in the patch, not clearing the isCapturedCache reduces compile times by another second. In some pathological cases I'm looking at, not-clearing this cache halves
 compile times (from 8s to 4s).</span></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">There are a few other examples such as TBAA's</font> getLeastCommonType and BasicAA's DecomposeGEP.</div>
<div><span><br>
</span></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">Ideally we'd would have something along the lines of:</font></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">void keepCaches()</font></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">void clearCaches(),</font></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">with the first one called just before building MemorySSA, and the second one called afterwards.</font></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000"><br>
</font></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">Again, I'm looking into how to make this available but also contain the lifespan of these internal caches to only
 "as long as it takes for this other analysis pass to be built".</font></div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Why then? Isn't the information valid so long as the IR is not mutated?</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><span><br>
</span></div>
<div><font face="Segoe UI, Segoe UI Emoji, Segoe UI Symbol,
              Lato, Helvetica Neue, Helvetica, Arial, sans-serif" color="#000000">Suggestions and feedback are most welcome!</font></div>
<div><span><br>
</span></div>
<div><span>Thanks,</span></div>
<div><span>Alina</span></div>
<div><span><br>
</span></div>
<div><span><br>
</span></div>
</div>
</div>
<br>
<fieldset class="gmail-m_4068406929172371701mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_4068406929172371701moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="gmail-m_4068406929172371701moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="gmail-m_4068406929172371701moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<pre class="gmail-m_4068406929172371701moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>

</blockquote></div>