<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 13, 2016 at 12:39 AM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><span style="font-size:10pt;line-height:1.5">Interesting. I'm not sure this is the right metric, however. There are lots of analyses that hold pointers to other analyses but don't need to. The analysis handle itself can be reacquired lazily if we care to do so. What's truly problematic is holding pointers into another analysis's data structures. To be concrete, holding a pointer to ScalarEvolution is not a fundamental problem because we could make the analysis reacquire the pointer at the start of every query. Holding SCEV* is the problem.</span></div></div></blockquote><div><br></div><div>Agreed. I suspect this is the dominant pattern.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><span style="font-size:10pt;line-height:1.5">FWIW, I still think this is common enough to design a solution that makes it easy to get this right.</span></div></div></blockquote><div><br></div><div>I somewhat suspect that it would be better to pass these in along the query path rather than have results cache them. The reason is that if the user of the analysis is aware of the other analyses it depends on, it will also be aware of that cost and the reality of potentially wanting to preserve them.</div><div><br></div><div>I'd be interested in us spending some time trying to make this refactoring and at least understanding how hard it is before we engineer a solution that makes the analysis management more complex.</div><div><br></div><div>So as you seemed to agree in your other email (sorry for the heavily branching thread) perhaps we should start with the potentially error prone approach now, and see how much iteration can move toward "nothing to do" by lifting things into the query path rather than the result object.</div></div></div>