<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:45 AM, Geoff Berry <span dir="ltr"><<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <p><br>
    </p>
    <br>
    <div>On 7/5/2016 8:21 PM, Daniel Berlin
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Jul 6, 2016 at 1:48 AM, Geoff
            Berry <span dir="ltr"><<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">gberry
              added a comment.<br>
              <br>
              Sorry if this isn't the right place, but I have a general
              question about what it means to preserve MemorySSA,
              specifically regarding the defining accesses of MemoryUse
              nodes.  Is the idea here that we make a best effort to
              keep the MemoryUse defining access links optimized (i.e.
              never pointing to a no-alias def)?</blockquote>
            <div><br>
            </div>
            <div>Yes. You should fix anything obviously
              affected/invalidated (this is a step past what memdep
              does, which is mostly nothing). But you should not have to
              redo the links themselves except those related to the
              load/store you touched.</div>
            <div><br>
            </div>
            <div>The *cache* (if any), needs more invalidation, however.
               </div>
            <div>So if you destroy a load, that means you pretty much
              have to do nothing.</div>
            <div>If you destroy a store, you either need fine-grained
              tracking, or destroy the entire cache.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Unless I'm missing something, this doesn't jibe with the caching
    walker changes under review (<a href="http://reviews.llvm.org/D21777" target="_blank">http://reviews.llvm.org/D21777</a>).  If
    the walker doesn't cache MemoryUse clobbering accesses (assuming
    that a MemoryUse's defining access is always the "best" clobber),
</div></blockquote><div><br></div><div>It doesn't cache, but it should still check.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">    then invalidating the cache when e.g. destroying a store isn't good
    enough since the cache is never consulted when querying about a
    MemoryUse's clobber.</div></blockquote><div><br></div><div>The cache is part of the walker, so if the walker has no cache and always looks, it doesn't matter.</div><div>If it is assuming the answer, that seems ... wrong.</div><div><br></div><div>I would expect it to do the one check.</div><div><br></div></div></div></div>