<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 2:40 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Sep 1, 2015 at 2:32 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Sep 1, 2015 at 2:10 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>><br>
> wrote:<br>
>><br>
>> This is a late reply -- the email somehow skipped my inbox.<br>
>><br>
>> > Philip and Sanjoy, out of curiosity do you guys use your own<br>
>> > instrumentation<br>
>> > placement for PGO? Is an IR-level PGO infrastructure upstream something<br>
>> > you<br>
>> > guys would be interested in?<br>
>> ><br>
>> > I think that 2. is something that once we have 1. we will be able to<br>
>> > evaluate better, but for now my opinion is that we should be able to<br>
>> > make<br>
>> > good progress without digging into that.<br>
>> ><br>
>> > I think that 3. is a no-brainer if it provides a really significant win,<br>
>> > but<br>
>> > without 1. we can't really measure its effect in isolation. It also has<br>
>> > a<br>
>> > usability problem since it requires feeding in an existing profile for<br>
>> > the<br>
>> > *instrumented* build, but if the benefit is very significant this may be<br>
>> > worth it for some users. We will probably be able to easily refactor 1.<br>
>> > as<br>
>> > needed into an MST approach that degrades gracefully to using static<br>
>> > heuristics in the absence of real profile information, so is not a<br>
>> > maintenance burden (maybe even helps by providing a good framework in<br>
>> > which<br>
>> > to develop effective static heuristics).<br>
>><br>
>> Regarding 3, I am not sure what usability issue are you referring to.<br>
>> Can you elaborate?<br>
><br>
><br>
> A user will need to provide a profile do the "instr-generate" phase<br>
<br>
</div></div>Late Instr-generate does not need a profile to work.</blockquote><div><br></div><div>Exactly. Therefore, 3. is a separate step (in particular the complexity of needing to pass extra files around).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> It works the same<br>
way (in terms of usability) as FE based instrumentation.  You can also<br>
use opt tool to do instrumentation.<br>
<span class=""><br>
>and as<br>
> Rong points out the "instr-use" phase will need to also be supplied that<br>
> same profile in order to interpret the counters. This adds significant<br>
> complexity to any PGO workflow and is not essential (it may be desirable at<br>
> some point, but it can be added to 1. as an incremental step at any time).<br>
<br>
</span>The PGO work flow does not change at all. The only requirement is that<br>
profile annotation pass in profile-use needs to be at the same point<br>
as where the instrumentation is inserted -- this is same as FE based<br>
method too, but more flexible.<br>
<span class=""><font color="#888888"><br>
David<br>
</font></span><div class=""><div class="h5"><br>
><br>
> -- Sean Silva<br>
><br>
><br>
>><br>
>><br>
>> thanks,<br>
>><br>
>> David<br>
>><br>
>><br>
>><br>
>><br>
>> ><br>
>> > For the time being, I think we can avoid discussion of 2. and 3. until<br>
>> > we<br>
>> > have more of 1. working. So I think it would be most productive if we<br>
>> > focus<br>
>> > this discussion on 1.<br>
>> ><br>
>> >><br>
>> >> Additionally, some of the overhead imposed by FE instrumentation is not<br>
>> >> really all that easy to get rid of.  You end up duplicating<br>
>> >> functionality<br>
>> >> that is more naturally implemented in the middle end.<br>
>> ><br>
>> ><br>
>> > Yeah, I was looking into a couple of other simple approaches and quickly<br>
>> > found out that I was basically replicating much of the sort of logic<br>
>> > that<br>
>> > the inliner already has.<br>
>> ><br>
>> > -- Sean Silva<br>
>> ><br>
>> >><br>
>> >><br>
>> >> I see the two approaches as supplementary, rather than complementary.<br>
>> >> One<br>
>> >> does not negate the other.  Some of the optimizations we'd do in the<br>
>> >> FE, may<br>
>> >> hurt coverage.  Instead, by instrumenting in the middle end, you can<br>
>> >> focus<br>
>> >> exclusively on performance (coverage be damned).<br>
>> >><br>
>> >><br>
>> >> Diego.<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> LLVM Developers mailing list<br>
>> >> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>