<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 5:46 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Apr 18, 2016 at 5:36 PM Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.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 Mon, Apr 18, 2016 at 5:14 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Mon, Apr 18, 2016 at 4:38 PM Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Now, the original design only accounted for profile information *within* a function body, clearly it needs to be extended to support intraprocedural information.</span></div></div></div></blockquote><div><br></div><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Not sure what you mean.  Profile data in general does not extend to IPA (we will reopen discussion on that soon), but profile summary is 'invariant'/readonly data, which should be available to IPA already.</div></div></div></div></blockquote><div><br></div></span><div>I don't know what you mean by "invariant" or readonly data here. I think that whether or not the profile information is mutated shouldn't influence the design invariants I described above.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I do not disagree with this. What I was saying is that the information can be made available to IPA in some form due to its readonly nature.</div></div></div></div></blockquote><div><br></div></span><div>While it can be made available, it is very hard to make it available even in a readonly form in the current pass manager.</div><div><br></div><div>You essentially have to avoid caching anything and make the API always re-examine the IR annotations in order to reflect changes to them. There are a few other "Immutable" analysis passes that abuse the legacy pass manager in this way.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Can you explain ? Why caching has to be avoided? What are these abuses?</div></div></div></div></blockquote><div><br></div></span><div>There is no invalidation of an immutable analysis pass in the old pass manager. So if you cache something, and it is changed, it won't really get updated unless you have a way to guarantee that every thing that updates the information *always* invalidates your cache (such as the ValueHandle machinery). But that style of cache invalidation often causes as many problems as it solves because it is very expensive.</div></div></div></blockquote><div><br></div><div>I checked the existing immutable passes briefly: </div><div><br></div><div>1) TTI and TLI look like true immutable passes -- information gets created during initialization and do not change</div><div>2) scope-based AA and type-based AA seem to be stateless, so they are ok. Basic AA has cache, but it is not an immutable pass.</div><div>3) assumptionCacheTracker uses cache (as the name implies), and it requires update</div><div>4) CFL AA -- has caching</div><div>5) MachineBranchProbabilityInfo -- it does not maintain any state  of its own -- but queries MBB.</div><div> </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_quote"><div><br></div><div>As a concrete example, if you want to walk the call graph to compute transitive profile information on call graph edges, </div></div></div></blockquote><div><br></div><div>What is your definition of 'transitive profile information'?</div><div><br></div><div> </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_quote"><div>you'll have no way to update this when the call graph changes other than to always recompute it when queried.</div></div></div></blockquote><div><br></div><div>Not sure about this until we know the definition of 'transitive profile info'.</div><div> </div><div> </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_quote"><span class=""><div> </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"><div><br></div><div> </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_quote"><div> That seems fine as a temporary thing. I don't *think* this kind of information would pose a significant compile time cost to recompute on each query, but I've not looked at the nature of the IPA queries you would want to make.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Note that for profile summary, since it is at program level (thus identical across modules), recomputing (re-reading from meta data) seems a waste -- though not to big as measured by Easwaran.</div></div></div></div></blockquote><div><br></div></span><div>The above only applies to things that change (function counts, etc). Genuinely immutable stuff is fine here.</div><div><br></div><div>However, there is another problem -- even if it won't be changed while the optimizer is running, immutable analysis run before *all* transform passes, including any pass that reads profile data and writes it into the IR. =/</div></div></div></blockquote><div><br></div><div><br></div><div>IIUC, Immutable analysis does not actually run?  Or for a truly immutable pass, we can consider its 'run' is during its construction/initialization.  However for any other immutable pass,  it can certainly run *after* some transformation passes as long as it is before any transformations that depend on it. For instance, MachineBranchProbabillityInfo does not exist until after MachineFunction is created, which is after many transformation passes (which also need to update profile meta data which MBPI depends on).  CFL AA is also created on demand, so its run is after transformation passes that do not need to query AA.   AssumptionCacheTracker is likewise.</div><div><br></div><div>David</div><div> </div></div><br></div></div>