<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><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Because of the limits of basic-aa, it isn't possible to guarantee this property after any code transformation, even in the limited case here, since the alias results for completely unrelated load/stores may have been affected, right?<br></blockquote><div>For the moment, yes, but this is 100% brokenness in basicaa that should be fixed, and will eventually be fixed.<br></div><div><br></div><div>There is simply never a good reason to have these limits in basicaa, they are symptomatic of basicaa having random stateless backwards walkers for properties that can be computed forwards and cached.</div><div>Everything that has such random backwards-walking limits should be moved out into a caching pass of some sort that is appropriately invalidated or recomputed.<br></div><div>Lest one worry, they pretty much never need to be recomputed, or at most, once (after serious loop optimizations).  Nothing changes their values because it would change the semantics of the program. Most of the time they simply reuse computations but still compute the same end result :P</div><div><br></div><div>In any case, your compiler's alias analysis results should not change at a basic level simply because you moved from 99 lines of code to 100 lines (and llvm's is the only one i know which does :( ).</div><div><br></div><div>BasicAA is also being used to do *way* too much.   This is a symptom of never having any real pointer analysis at all, and so people use basicaa to try to figure out pointer analysis problems.<br></div><div><br></div><div>All of this is a  borked design at this point.  BasicAA started off with good intentions, but it needs a lot of love at this point :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://reviews.llvm.org/D8688" rel="noreferrer" target="_blank">http://reviews.llvm.org/D8688</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>