<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2016, at 10:07 AM, Adam Nemet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jul 13, 2016, at 2:02 AM, Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_extra"><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote">On Wed, Jul 13, 2016 at 1:50 AM, Chandler Carruth<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:chandlerc@gmail.com" target="_blank" class="">chandlerc@gmail.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><span class=""><div dir="ltr" class="">On Wed, Jul 13, 2016 at 1:40 AM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank" class="">chisophugis@gmail.com</a>> wrote:<br class=""></div></span><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jul 13, 2016 at 12:39 AM, Hal Finkel<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""></span><span class=""><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 class=""><div class="" style="font-family: arial, helvetica, sans-serif; font-size: 10pt;">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.</div></div></blockquote><div class=""><br class=""></div></span></div></div></div><span class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="">Are you thinking of instead holding a pointer to the analysis manager?</div></div></div></div></div></span></blockquote><div class=""><br class=""></div><div class="">I'm really concerned with using this approach as the common case. It triggers the run of the analyses at very strange points (mid-query of some other analysis) and forces us to pay the analysis manager lookup overhead on every query. For many analyses, this overhead is larger than the actual query.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, the overhead is my main concern. (also, this would be very difficult to coexist with the old PM so at least in the immediate future isn't an option)</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">There may be cases where this is the only sane way to manage things, but this should be the exception rather than the rule IMO.</div><span class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </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 class=""><div class="" style="font-family: arial, helvetica, sans-serif; font-size: 10pt;">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.<br class=""></div></div></blockquote><div class=""><br class=""></div></div></div></div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA holds Loop* too)<br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Note that Loop (and SCC) are somewhat special as they are IRUnitTs and might as a consequence be more reasonable to hold on to and expect definitive invalidation to occur. But I say "might". I think this will be case-by-case depending on how they're being used.</div><span class=""><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""></div><div class="">New updated rendering at<span class="Apple-converted-space"> </span><a href="http://reviews.llvm.org/F2161258" target="_blank" class="">http://reviews.llvm.org/F2161258</a><span class="Apple-converted-space"> </span>(DependenceAnalysis was missing some edges in my previous rendering and I didn't have and I've added LoopAccessAnalysis; I've updated<span class="Apple-converted-space"> </span><a href="http://reviews.llvm.org/P6603" target="_blank" class="">http://reviews.llvm.org/P6603</a>). Which other analyses vend data objects that others might hold pointers to?</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">SCEV, Loop, SCC, DomTreeNode, and Region leap immediately to mind. and 3 of those are what would be IRUnitTs (Region being the third, and its weird and likely won't be in the new PM ever).</div></div></div></blockquote></div><br class=""></div><div class="gmail_extra">Looking around a bit:</div><div class="gmail_extra">Looks like DomTreeNode isn't held by anything currently.</div><div class="gmail_extra">Pointers to Loop are only held by LAA as far as I can tell.</div><div class="gmail_extra">CallGraphSCC objects are only used by GlobalsAA but only for a "recalculate" step.</div><div class="gmail_extra">Region's data structures don't seem to be held by anything.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">So it seems like LAA is the main offender in this regard.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think one main reason that analysis passes used to do this was to work around limitations in the old PM. Like LAA wasn’t a loop pass so as a function pass it did lazy computation for loops. Thus it had to hold on to the input analyses to compute the per-loop analysis result. I am hoping that this use case will go away with the new PM. There may be a way to refactor LoopAccessInfo to reflect this, hopefully the old PM won’t stand in the way.</div></div></div></blockquote><div><br class=""></div>r275322 removes the reference to AA from the analysis result since it’s only used at ctor time. I think that we should be able to remove everything except for SCEV and Loop.</div><div class=""><br class=""></div><div class="">Adam</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div><div class="">SCEV might pose another problem though. Caching is per Value there, so that is probably a genuine use case when we need to keep input analysis alive until the main pass is alive.</div><div class=""><br class=""></div><div class="">A few more other thoughts on this topic.</div><div class=""><br class=""></div><div class="">Can we perhaps have a special reference type for passes to reference other passes, something like a CallbackVH for passes and them somehow disallow holding onto passes via a pointer?</div><div class=""><br class=""></div><div class="">There could also be a way to verify correctness. We could force-invalidate all passes that the pass does not declare to depend on, then hopefully bugs will unconditionally present themselves independent of the pipeline.</div><div class=""><br class=""></div><div class="">Adam</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="gmail_extra"><br class=""></div><div class="gmail_extra">-- Sean Silva</div></div><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">_______________________________________________</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">LLVM Developers mailing list</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="mailto:llvm-dev@lists.llvm.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">llvm-dev@lists.llvm.org</a><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">LLVM Developers mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:llvm-dev@lists.llvm.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">llvm-dev@lists.llvm.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br class=""></body></html>