<div dir="ltr">Yeah, that sounds like a fun bug. I'll take a look later today and see what I can find out. :)<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 2:55 PM, 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">
    <p>Hi guys,</p>
    <p>I think I have run into another CachingMemorySSAWalker cache
      bug.  It's a bit tricky to reproduce, so I'd like to start by
      trying to show you what is happening when running EarlyCSE with my
      local changes to use MemorySSA.  I've attached a debug log that
      shows that the value returned by getClobberingMemoryAccess(Inst)
      after a call to removeMemoryAccess is wrong.  The MemorySSA node
      in question is MemoryUse(7), and the corruption happens after a
      call to remove MemoryUse(2), at which point its clobber value
      changes to '1 = MemoryDef(liveOnEntry)'.  The interesting thing is
      that is doesn't seem to be the first call to
      getClobberingMemoryAccess after the removal that causes the
      corruption, but rather the second.  You'll notice that I added
      calls to getClobberingMemoryAccess when doing MSSA.dump(), which
      is what I'm using to attempt to figure out when the cache gets
      corrupted.<br>
    </p>
    Hopefully this is enough information to debug the problem.  If not
    perhaps we can look at getting my EarlyCSE changes checked in in a
    disabled state so you can reproduce the problem directly.  I'm also
    happy to help debug it farther.<span><font color="#888888"><br>
    <pre cols="72">-- 
Geoff Berry
Employee of Qualcomm Innovation Center, Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
  </font></span></div>

</blockquote></div><br></div></div>