<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Xinliang David Li" <davidxl@google.com><br><b>To: </b>"Chandler Carruth" <chandlerc@gmail.com><br><b>Cc: </b>"Hal Finkel" <hfinkel@anl.gov>, "via llvm-dev" <llvm-dev@lists.llvm.org>, "Mehdi Amini" <mehdi.amini@apple.com><br><b>Sent: </b>Monday, April 18, 2016 5:45:21 PM<br><b>Subject: </b>Re: [llvm-dev] Move InlineCost.cpp out of Analysis?<br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 3:00 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Apr 18, 2016 at 2:48 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br></div></span><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><span class=""><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><br><hr><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Xinliang David Li" <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>><br></blockquote></div></div></span><span class=""><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 18, 2016 at 2:33 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div>In the current case at stake: the issue is that we can't make the Analysis library using anything from the ProfileData library. Conceptually there is a problem IMO.</div></div></div></blockquote><div><br></div><div><br></div><div>Yes -- this is a very good point.</div></div></div></div></blockquote></div></div><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"></blockquote>Independent of anything else, +1.<br></div></div></span></blockquote><div><br></div><div>The design of ProfileData and reading profile information in the entire middle end had a really fundamental invariant that folks seem to have lost track of:</div></div></div></blockquote><div><br></div><div>Not sure about what you mean by 'lost track of'. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>a) There is exactly *one* way to get at profile information from general analyses and transforms: a dedicated analysis pass that manages access to the profile info.</div></div></div></blockquote><div><br></div><div><br></div><div>This is not the case as of today. BPI is a dedicated analysis pass to manage branch probability profile information, but this pass is only used in limited situations (e.g, for BFI, profile update in jump-threading etc) -- using it it requires more memory as well as incremental update interfaces. Many transformation passes simply skip it and directly access the meta data in IR.</div><div id="DWT13904"><br></div></div></div></div></blockquote>Really? Which ones? I see a number of passes that know about profiling metadata so they can preserve it, or transfer it across restructuring, but nothing that really interprets it on its own in a non-trivial way.<br><br>I'm not sure this is desirable regardless.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>b) There is exactly *one* way for this analysis to compute this information from an *external* profile source: profile metadata attached to the IR.</div></div></div></blockquote><div><br></div><div><br></div><div>This is the case already -- all profile data are annotated to the IR via analysis pass (or in FE based instrumentation case, by FE during llvm code gen).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>c) There could be many external profile sources, but all of them should be read and then translated into metadata annotations on the IR so that serialization / deserialization preserve them in a common format and we can reason about how they work.</div><div><br></div></div></div></blockquote><div><br></div><div>This should be the case already -- for instance sample and instrumentation based IR share the same annotation for branch probability, entry count and profile summary.</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>This layering is why it is only a transform that accesses ProfileData -- it is responsible for annotating the IR and nothing else. <span style="line-height: 1.5;">Then the analysis uses these annotations and never reads the data directly.</span></div><div><span style="line-height: 1.5;"><br></span></div><div><span style="line-height: 1.5;">I think this is a really important separation of concerns as it ensures that we don't get an explosion of different analyses supporting various different subsets of profile sources.</span></div><div><span style="line-height: 1.5;"><br></span></div><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 id="DWT13905">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>IPA-level profiling data might be invariant, but inside the function it certainly need to change because the code inside functions is changed (branches are eliminated, transformed into selects, etc.)<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><span style="line-height: 1.5;"> But I would still expect that to follow a similar layering where we first read the data into IR annotations, then have an analysis pass (this time a module analysis pass in all likelihood) that brokers access to these annotations through an API that can do intelligent things like synthesizing it from the "cold" attribute or whatever when missing.</span></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><span style="line-height: 1.5;"><br></span></div><div><span style="line-height: 1.5;">-Chandler</span></div></font></span></div></div>
</blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>