<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 18, 2016 at 5:36 PM Xinliang David Li <<a href="mailto:davidxl@google.com">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><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><br></div><div>As a concrete example, if you want to walk the call graph to compute transitive profile information on call graph edges, 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 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><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>