<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jul 12, 2016 at 11:00 PM Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 12, 2016 at 9:00 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</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 style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">I think that (2) is the right answer, but I'm not sure that the dance needs to be all that complicated. Each analysis can contain a list (small vector) of other analysis that depend on it, and the interface to get an analysis can take a pointer to add to this list. When an analysis is invalidated, the manager can queue the invalidation of the others in the list.<br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>At least with the current arrangement, there is not just one AnalysisManager, but rather one per IRUnitT (with the <X>AnalysisManager<Y>Proxy analyses to go between them). So a pointer to the analysis is not enough; you also need a pointer to the AnalysisManager that is caching the result of that analysis. Since the invalidation method is actually typed to take the IRUnitT, you now need a way to store a reference to the other analysis manager in a type-erased way (since e.g. a function analysis can depend on a module analysis or vice versa).</div><div><br></div><div>It's sort of hairy and potentially requires quite a bit of storage (relative to the other PM data structures). E.g. a module analysis that queries various function analyses on each function will create O(NumFunctionPassesUsed * NumFunctionsInModule) back pointers to itself. Also, what happens if the module analysis is invalidated? Do we need to store even more pointers from the module analysis back to the function analyses so that it can "unregister" itself as a dependency?</div><div><br></div><div>Having a single AnalysisManager that stores analyses for all the different IRUnitT's might somewhat simplify this, but it would still be pretty complicated I think.</div></div></div></div></blockquote><div><br></div><div>Yea, I largely agree. I'd try out overriding the invalidate method and triggering on the necessary set first, and see how that goes before we go down this road.</div></div></div>