<div dir="ltr">(as an aside, Hal, i'd love your opinion on whether MemoryLocation should really be something that handles calls as well.  Or, alternatively, at least getModRefInfo uses something that does without people having to know about it.<div><br></div><div>If we used something like MemoryLocOrCall [obviously this is just a simple union class]), we could  simplify parts of the AA API.  I also wouldn't need it to hack around things in the AA API's getModRefInfo.<br></div><div><br></div><div>Right now we have this artificial distinction where we have things that use pointers get MemoryLocations, other things get ImmutableCallSites. This kinda makes sense for alias() (though more advanced aa's are just implementing that in terms of mod ref info they have created).</div><div><br></div><div>However, the current AA API operates on both *anyway*, and the overloads you get are confusing.</div><div><br></div><div>IE we have:<br><pre class="gmail-fragment" style="font-family:monospace,fixed;font-size:9pt;border:1px solid rgb(196,207,229);background-color:rgb(251,252,253);padding:4px 6px;margin:4px 8px 4px 2px;overflow:auto;word-wrap:break-word;line-height:15px;color:rgb(0,0,0)">00333 <span class="gmail-comment" style="color:rgb(128,0,0)"></span>  <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/namespacellvm.html#a3994f46b116d674bc6d490897b9f60b9" title="Flags indicating whether a memory access modifies or references memory." style="color:rgb(70,101,162);text-decoration:none">ModRefInfo</a> <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1AAResults.html#ad5fb719206e3111dd6d4216d954395d5" title="getModRefInfo (for call sites) - Return information about whether a particular call site modifies or ..." style="color:rgb(70,101,162);text-decoration:none">getModRefInfo</a>(<a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1ImmutableCallSite.html" title="ImmutableCallSite - establish a view to a call site for examination." style="color:rgb(70,101,162);text-decoration:none">ImmutableCallSite</a> <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/namespacellvm.html#a488b094cb42981f433eaefd848483445a4f8b402109de7f745e3e37bb2dee4318" style="color:rgb(70,101,162);text-decoration:none">CS</a>, <span class="gmail-keyword" style="color:rgb(0,128,0)">const</span> <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1MemoryLocation.html" title="Representation for a specific memory location." style="color:rgb(70,101,162);text-decoration:none">MemoryLocation</a> &Loc);
</pre></div><div>and</div><div><pre class="gmail-fragment" style="font-family:monospace,fixed;font-size:9pt;border:1px solid rgb(196,207,229);background-color:rgb(251,252,253);padding:4px 6px;margin:4px 8px 4px 2px;overflow:auto;word-wrap:break-word;line-height:15px;color:rgb(0,0,0)"><a name="l00751" style="color:rgb(61,87,140)"></a><a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1AAResultBase_1_1AAResultsProxy.html#a537129572d9230c146f0533d1286cce2" style="color:rgb(70,101,162);text-decoration:none">00751</a>     <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/namespacellvm.html#a3994f46b116d674bc6d490897b9f60b9" title="Flags indicating whether a memory access modifies or references memory." style="color:rgb(70,101,162);text-decoration:none">ModRefInfo</a> <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1AAResultBase_1_1AAResultsProxy.html#a537129572d9230c146f0533d1286cce2" style="color:rgb(70,101,162);text-decoration:none">getModRefInfo</a>(<a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1ImmutableCallSite.html" title="ImmutableCallSite - establish a view to a call site for examination." style="color:rgb(70,101,162);text-decoration:none">ImmutableCallSite</a> CS1, <a class="gmail-code" href="http://llvm.org/docs/doxygen/html/classllvm_1_1ImmutableCallSite.html" title="ImmutableCallSite - establish a view to a call site for examination." style="color:rgb(70,101,162);text-decoration:none">ImmutableCallSite</a> CS2);</pre></div><div><br></div><div>etc</div><div><br></div><div><br></div><div>You pretty much can't use getModRefInfo right now unless you check whether the instructions you are trying to get mod ref info about are  0, 1, or 2 calls.  Because calls don't have memorylocs, so you can't just always call ::get on them.</div><div>You then have to call the right overloads yourself.</div><div>That seems wrong.  </div><div>(I'll ignore the fact that you also have to check whether you are holding a fence inst, since you can't get memorylocations for those either, and ::get will just crash.  )</div><div><br></div><div>Right now the number of overloads is also ... high, and while we fixed the last immediate problem i remember (where random things would get overloaded to ImmutableCallSite versions when they weren't calls), staring at the number of getModRefInfo overloads, i'm not sure i believe the way we have it structured makes sense.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 8:26 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can get rid of UseInst too, MemoryLocOrCall will take a MemoryUse directly :)<div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 8:20 PM, Sebastian Pop <span dir="ltr"><<a href="mailto:sebpop@gmail.com" target="_blank">sebpop@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Oct 12, 2016 at 10:05 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:<br>
> There is actually a much simpler fix you sholdl use.<br>
><br>
> return instructionClobbersQuery(MD, MU MemoryLocOrCall(MU), AA);<br>
><br>
> You need to move that version of instructionClobbersQuery up, but it was<br>
> built to always do the right thing.<br>
><br>
> Also note it will properly handle a case you are not: Fences do not have<br>
> memorylocations, and calling get on them will also crash.<br>
><br>
<br>
</span>Right. I will commit the attached patch after testing.<br>
<br>
Thanks,<br>
Sebastian<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>