<div dir="ltr"><br><div class="gmail_extra"><br><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 class=""><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>Can you explain ? Why caching has to be avoided? What are these abuses? </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> 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>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><br></div><div>David</div><div><br></div><div><br></div><div> </div></div><br></div></div>