<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 11:29 AM, Rong Xu <span dir="ltr"><<a href="mailto:xur@google.com" target="_blank">xur@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"><span class="">On Wed, Mar 8, 2017 at 11:24 AM, 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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Mar 8, 2017 at 11:11 AM, Rong Xu via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">xur added a comment.<br>
<span><br>
In <a href="https://reviews.llvm.org/D28966#694902" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2896<wbr>6#694902</a>, @davidxl wrote:<br>
<br>
> The optimization pass should be split into two phases as IC promotion. The annotation part should probably  be merged with the instrumentation patch. The transformation patch should be done in the same pass as IndirectCallPromotion.<br>
<br>
<br>
</span>Is there a good reason for doing the transformation late?  Here I don't do the annotation and instead, I do the transformation directly in the same pass. The main reason we have annotations in indirect-call-promotion is we need to call it late (in LTO or ThinLTO). Another reason I'm reluctant to use annotation is that we need to maintain/update it (for inline and unroll, for example).<br></blockquote><div><br></div></span><div>Unlike the indirect call promotion, which enables more inlining, stringOp value prof transformation can lead to increased function body size that negatively affect inlining decisions. </div><div><br></div></div></div></div></blockquote></span><div>This is true. But the profile we collect is before inline.  The count values does not have context information. The only thing we can do is to scale down based on the edge count.</div></div></div></div></blockquote><div><br></div><div>Right, but there is no profile meta-data update needed either.  The value counts total should match the enclosing BB count. If not, scale it before deciding profit.  Even though it does not have full context sensitivity, it provides some benefit of context hotness. When the call context const prop the size parameter, the transformation can be skipped as well.</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>This also required a separated pass -- we don't have this for indirect-call promotion either (the LTO part of the ICP is different).</div></div></div></div></blockquote><div><br></div><div>Indirect Call Promotion is a separate pass. </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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Rong<br>
<br>
<br>
<a href="https://reviews.llvm.org/D28966" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2896<wbr>6</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div>