<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 11:39 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Tue, Jul 12, 2016 at 11:34 PM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 12, 2016 at 11:32 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Jul 12, 2016 at 10:57 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Yea, this is a nasty problem.</div><div><br></div><div>One important thing to understand is that this is specific to analyses which hold references to other analyses. While this isn't unheard of, it isn't as common as it could be. Still, definitely something we need to address.</div></div></div></blockquote><div><br></div></span><div>We can call this type of dependencies (holding references) hard-dependency. The soft dependency refers to the case where analysis 'A' depends on 'B' during computation, but does not need 'B' once it is computed.</div><div><br></div><div>There are actually quite a few examples of hard-dependency case. For instance LoopAccessInfo, LazyValueInfo etc which hold references to other analyses.</div><div><br></div><div>Problem involving hard-dependency is actually easier to detect, as it is usually a compile time problem. Issues involving soft dependencies are more subtle and can lead to wrong code gen.</div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Did you mean to say that soft-dependency problems are easier to detect? At least my intuition is that soft-dependency is easier because there is no risk of dangling pointers to other analyses.<br></div></div></div></div></blockquote><div><br></div></span><div>The issue is that the fact that there is *any* dependency isn't clear.</div><div><br></div><div>However, I think the only real problem here are these "hard dependencies" (I don't really like that term though). For others, only an analysis that is *explicitly* preserved survives. So I'm not worried about the fact that people have to remember this.</div><div><br></div><div>The question is how often there are cross-data-structure references. David mentions a few examples, and I'm sure there are more, but it isn't clear to me yet whether this is pervasive or occasional.</div></div></div></blockquote><div><br></div><div><div><br class="">I just did a quick run-through of PassRegistry.def and this is what I found:</div><div><br></div><div>Module analyses: 0/5 hold pointers to other analyses</div><div>CallGraph: No pointers to other analyses.</div><div>LazyCallGraph: No pointers to other analyses.</div><div>ProfileSummaryAnalysis: No pointers to other analyses.</div><div>TargetLibraryAnalysis: No pointers to other analyses.<br></div><div>VerifierAnalysis: No pointers to other analyses.</div><div><br></div><div>Module alias analyses: 1/1 keeps pointer to other analysis.</div><div>GlobalsAA: Result keeps pointer to TLI (this is a function analysis).</div><div><br></div><div>Function analyses: 9/17 keep pointers to other analysis</div><div>AAManager: Its Result holds TLI pointer and pointers to individual AA result objects.</div><div>AssumptionAnalysis: No pointers to other analyses.<br></div><div>BlockFrequencyAnalysis: Its Result holds pointers to LoopInfo and BPI.<br></div><div>BranchProbabilityAnalysis: Stores no pointers to other analyses. (uses LoopInfo to "recalculate" though)<br></div><div>DominatorTreeAnalysis: Stores no pointers to other analyses.<br></div><div>PostDominatorTreeAnalysis: Stores no pointers to other analyses.</div><div>DemandedBitsAnalysis: Stores pointers to AssumptionCache and DominatorTree<br></div><div>DominanceFrontierAnalysis: Stores no pointers to other analyses. (uses DominatorTreeAnalysis for "recalculate" though).<br></div><div>LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no pointers.<br></div><div>LazyValueAnalysis: Stores pointers to AssumptionCache, TargetLibraryInfo, DominatorTree.<br></div><div>DependenceAnalysis: Stores pointers to AliasAnalysis, ScalarEvolution, LoopInfo</div><div>MemoryDependenceAnalysis: Stores pointers to AliasAnalysis, AssumptionCache, TargetLibraryInfo, DominatorTree<br></div><div>MemorySSAAnalysis: Stores pointers to AliasAnalysis, DominatorTree<br></div><div>RegionInfoAnalysis: Stores pointers to DomTree, PostDomTree, DomFrontier<br></div><div>ScalarEvolutionAnalysis: Stores pointers to TargetLibraryInfo, AssumptionCache, DominatorTree, LoopInfo</div><div>TargetLibraryAnalysis: Has no dependencies<br></div><div>TargetIRAnalysis: Has no dependencies.<br></div><div><br></div><div>Function alias analyses: 3/5 keep pointers to other analyses</div><div>BasicAA: Keeps pointers to TargetLibraryInfo, AssumptionCache, DominatorTree, LoopInfo</div><div>CFLAA: Keeps pointer to TargetLibraryInfo</div><div>SCEVAA: Keeps pointer to ScalarEvolution</div><div>ScopedNoAliasAA: No dependencies<br></div><div>TypeBasedAA: No dependencies<br></div><div><br></div><div><br></div><div>Total: 13/28 analyses (~50%) hold pointers to other analyses.</div><div>Of the 15/28 analyses that don't hold pointers, 12/15 simply have no dependencies. Only 3/15 (BPI, LoopInfo, DominanceFrontier) have dependencies that are used just for a "recalculate" step that retains no pointers.</div><div>So I think it is fair to say that analyses which hold pointers to other analyses is not an exceptional case. In fact, analyses that use other analyses just for a "recalculate" step seems to be the exceptional case (only 3/28 or about 10%)</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div>Since I like to visualize things, here is a quick graph of the dependencies between analyses which hold pointers to each other.</div><div>Edge A -> B indicates "A can/does hold a pointer to B".</div><div>dot file: <a href="http://reviews.llvm.org/P6603">http://reviews.llvm.org/P6603</a></div><div>rendering: <a href="http://reviews.llvm.org/F2161058">http://reviews.llvm.org/F2161058</a></div></div><div><br></div><div>(I've been a bit loose with terminology here. A lot of the times that I say "analysis" I mean "the analysis' result object" or I use the name of the analysis interchangeably with the analysis result object)</div></div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>And even then it isn't clear how onerous explicitly managing this in invalidate overrides will be.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>-- Sean Silva</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>David</div></font></span><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Some ideas about mitigating and fixing it below.</div><span><div dir="ltr"><br></div><div dir="ltr">On Tue, Jul 12, 2016 at 6:15 PM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="line-height:1.5">How should we solve this? I see two potential solutions:</span><br></div><div><div>1. Analyses must somehow list the analyses they depend on (either by overriding "invalidate" to make sure that they invalidate them, or something "declarative" that would allow the AnalysisManager to walk the transitive dependencies).</div></div></div></blockquote><div><br></div></span><div>I think this is the right approach. I would personally start by overriding the invalidate callback everywhere that it is necessary, and see how bad that becomes.</div><div><br></div><div>If it becomes common and burdensome, then we can change the way invalidation works such that the analysis manager is aware of the preserved analysis set in more detail, and have it build up the necessary data structures to know in-advance whether it must make an explicit invalidate call.</div><div><br></div><div>However, I suspect this may not be *too* bad for two reasons:</div><div><br></div><div>a) As I mentioned above, I'm hoping there aren't *too* many handles between different analyses. But I've not done a careful examination, so we can check this.</div><div><br></div><div>b) For many analyses that might trigger this, I think we have a simpler option. If the analysis is *immutable* for any reason -- that is, it overrides its invalidate routine to always return "false" the way TargetLibraryInfo should (although I'm not sure it does currently), we shouldn't need to do this as it shouldn't be getting cleared out. Does this make sense? Do others see anything I'm missing with that approach?</div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>2. The AnalysisManager must do a somewhat complicated dance to track when analyses call back into it in order to get other analyses.</div></div></div></blockquote><div><br></div></span><div>I would really rather avoid this, as currently the analysis manager's logic here is very simple, and in many cases we only need the analyses to *compute* our result, not to embed it. I'm tihnking of stuff like Dominators is used to build LoopInfo, but there isn't a stale handle there.</div><div><br></div><div><br></div><div><br></div><div>There is another aspect of course in that if something is preserving LoopInfo, it really should be preserving Dominators too...</div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div></div></div></blockquote></span></div></div>
</blockquote></div><br></div></div>