<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 8:21 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 lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Okay, do you think this case needs a unittest?</span></p></div></div></blockquote><div><br></div><div>I would think the right answer is to have a verifyRemoved(X), and call it with expensive checks on (from invalidateInfo)</div><div><br>Have it verify that, after invalidation, no removed memoryAccesses appear in the cache.</div><div><br></div><div>This would be a quite expensive check  with the current caching scheme, but probably helpful for debugging.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">  I think I can construct one by comparing the results from getClobberingMemoryAccess before and after a call to removeMemoryAccess to make sure they’re different, but I don’t know how much of a pain it will be to construct the test IR programmatically.  </span></p></div></div></blockquote><div><br></div><div>Constructing the testIR programmatically is pretty easy, but i don't know that a unittest without access to the internals will be able to verify the cache state.</div><div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p><span class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><div style="border:dashed #2f6fab 1.0pt;padding:12.0pt 12.0pt 12.0pt 12.0pt;background:#f9f9f9"><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9;border:none;padding:0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--<u></u><u></u></span></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9;border:none;padding:0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Geoff Berry<u></u><u></u></span></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9;border:none;padding:0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Employee of Qualcomm Innovation Center, Inc.<u></u><u></u></span></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9;border:none;padding:0in"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></span><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Daniel Berlin [mailto:<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>] <br><b>Sent:</b> Wednesday, April 20, 2016 3:45 PM<br><b>To:</b> Geoff Berry <<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>><br><b>Cc:</b> George Burgess <<a href="mailto:gbiv@google.com" target="_blank">gbiv@google.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span></p><div><div class="h5"><br><b>Subject:</b> Re: [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issue<u></u><u></u></div></div><p></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Oh, crap.<u></u><u></u></p><div><p class="MsoNormal">I wasn't thinking hard enough about the case you described.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Okay. So your patch is right as the conservative thing to do.<u></u><u></u></p></div><div><p class="MsoNormal">The real problem here is that we don't know what cache entries point to other cache entries.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">We do in some special cases (If the use list contains only memoryuses, we know all the cache entries that need invalidation), but not in general.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Given most queries are about loads and not stores, and loads don't even need to be cached after memoryssa is built anyway (they will already directly point to the nearest clobbering definition), i think we should just apply your patch.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Apr 20, 2016 at 12:06 PM, Geoff Berry <<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>> wrote:<u></u><u></u></p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Sounds good.  This isn’t holding me up so I’ll just try to keep an eye out for these changes.</span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I’ve attached an example IR file and debug log of where the caching is going bad.  It depends on my changes to EarlyCSE, but hopefully it is clear from the debug output what is going on.  Let me know if there is a better way to get this repro case to you.  Also, I’ll be on IRC for the next couple of hours if you would like to have a quicker discussion.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><div style="border:dashed #2f6fab 1.0pt;padding:12.0pt 12.0pt 12.0pt 12.0pt"><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--</span><u></u><u></u></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Geoff Berry</span><u></u><u></u></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Employee of Qualcomm Innovation Center, Inc.</span><u></u><u></u></p><p class="MsoNormal" style="line-height:15.6pt;background:#f9f9f9"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</span><u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Daniel Berlin [mailto:<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>] <br><b>Sent:</b> Wednesday, April 20, 2016 1:06 PM<br><b>To:</b> Geoff Berry <<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>>; George Burgess <<a href="mailto:gbiv@google.com" target="_blank">gbiv@google.com</a>><br><b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br><b>Subject:</b> Re: [LICM][MemorySSA] Converting LICM pass to use MemorySSA to avoid AliasSet collapse issue</span><u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Apr 20, 2016 at 9:58 AM, Geoff Berry <<a href="mailto:gberry@codeaurora.org" target="_blank">gberry@codeaurora.org</a>> wrote:<u></u><u></u></p><div><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Daniel,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks for the info.  I’ve started looking into converting EarlyCSE to use MemorySSA first since 1) I don’t think it needs any additional MemorySSA update API and 2) the particular case I’m looking at needs EarlyCSE to catch more load cases before LICM to be profitable.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I have a prototype working, but have run into two issues:</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">readonly calls are treated as clobbers by MemorySSA which leads to extra walking of MemoryDefs to not regress some EarlyCSE test cases.  This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet.</span><u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">George is working on the optimizations, of which this is one.<u></u><u></u></p></div><div><p class="MsoNormal">I think this is one of the ones his current patch (under review) addresses.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2)</span><span style="font-size:7.0pt;color:#1f497d">      </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed.  In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map.  However, this same call node is present as a value in the CachedUpwardsClobberingAccess map,</span><u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Unless i'm missing something, this should not have happened, and we should assert they are not being added to the cache.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">The truth is the caching parts are complicated and ugly. It was meant to be a pretty simple cache, but it's known to be inefficient (memory wise) and it's on the list of things to clean up and make sane.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Do you have a testcase where this happens?<u></u><u></u></p></div><div><p class="MsoNormal">A quick glance says we check whether it's a call in all the right places, which means there must be a place we are not *setting* isCall properly.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></div></div></div></div></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br></div></div>