<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 2, 2016 at 3:44 PM, Easwaran Raman <span dir="ltr"><<a href="mailto:eraman@google.com" target="_blank">eraman@google.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">IMO, multiple levels of hotness/coldness is not very useful.  If that proves to be beneficial, tweaking the hotness cutoffs and the inline threshold for hot/cold sites should get to similar performance on average without the additional complexity. </div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div>I think it can be useful -- even though the inliner's implementation may choose to not use the information.</div><div><br></div><div>Suppose we have compile time/import size budget, having more fine grained information helps the importer prioritize the callsites based on that information -- similar to priority based inliner. Besides I don't see how it adds more complexity.</div><div><br></div><div>David</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 class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 2, 2016 at 3:32 PM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-3225306175082276708h5">On Fri, Sep 2, 2016 at 3:30 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 2, 2016 at 3:16 PM, Piotr Padlewski<br>
<span><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br>
><br>
><br>
> 2016-09-02 15:04 GMT-07:00 Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>>:<br>
>><br>
>> On Fri, Sep 2, 2016 at 2:58 PM, Piotr Padlewski<br>
>> <<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> > I am working right now on importing based on PGO/FDO data. There is one<br>
>> > issue that I found - when we calculate the list of imports, we can't get<br>
>> > the<br>
>> > ProfileSummaryInfo, which is the best and I<br>
>> > think only valid way of checking if callsite/callee is hot<br>
>> > (isHotCount()).<br>
>> > There are 2 solutions that I come up with Teresa and Easwaran:<br>
>> ><br>
>> > 1. Add PGO data to summary<br>
>> > 2. Replace CalleeInfo::ProfileCount with enum {None, Cold, Hot} computed<br>
>> > during computing summary.<br>
>><br>
>><br>
>> Don't we already have edge profile count in the callgraph summary?<br>
>> I think what is missing is the Profile SUmmary data itself -- that one<br>
>> should be copied over to thinLTO summary so that the importing<br>
>> analysis can use. However I we should not need to duplicate the<br>
>> information in every module.<br>
>><br>
>> David<br>
>><br>
> Yes we do have edge profile cout, but in order to compare it with global<br>
> couts we need Profile Summary as you said.<br>
> If we will follow 2) then we won't have to duplicate the data.<br>
<br>
</span>Ok -- basically the profile summary is already consumed before<br>
writing.  If you go this route, I think you need more enum values for<br>
fine tuning: for instance hot_10 --> 10 percentile hotness, ... hot_90<br>
etc, and cold_99, cold_999 etc.<br></blockquote><div><br></div></div></div><div>Right, that relates to my question about how the inliner will eventually use the same profile summary data, and whether it will be useful to distinguish between various levels of hotness.</div><span class="m_-3225306175082276708HOEnZb"><font color="#888888"><div><br></div><div>Teresa</div></font></span><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="m_-3225306175082276708m_-8401813124042249633HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="m_-3225306175082276708m_-8401813124042249633HOEnZb"><div class="m_-3225306175082276708m_-8401813124042249633h5"><br>
<br>
><br>
>><br>
>> ><br>
>> > I like the 2. much more. It will reduce the summary size slightly and I<br>
>> > don't think we will need ProfileCount anywhere else.<br>
>> ><br>
>> > The other thing I would like to mention is that I think we should start<br>
>> > using the summary versioning and drop support of old version.<br>
>> > ThinLTO doesn't have enough users right now and parsing many versions of<br>
>> > summary will just add additional cost, that will start to grow.<br>
>> ><br>
>> > Piotr<br>
><br>
><br>
</div></div></blockquote></span></div><br><br clear="all"><span><div><br></div>-- <br><div class="m_-3225306175082276708m_-8401813124042249633gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</span></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>