<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 4:13 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.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><div>Easwaran Raman <<a href="mailto:eraman@google.com" target="_blank">eraman@google.com</a>> writes:<br>
> eraman created this revision.<br>
> eraman added reviewers: davidxl, bogner.<br>
> eraman added subscribers: dnovillo, llvm-commits.<br>
> eraman set the repository for this revision to rL LLVM.<br>
><br>
> This patch uses the higher inline-hint-threshold for callees that are<br>
> considered hot. The threshold for hotness is the one used in CFE to<br>
> apply inline hint on hot callees - callee's entry count >= 30% of max<br>
> function entry count. The idea is to remove that code from the<br>
> frontend and make the PGO based inlining decisions in the inliner<br>
> itself. What we really want is callsite based hotness thresholds, but<br>
> that is a heuristic change that needs tuning and will be done in a<br>
> separate patch.<br>
><br>
> Repository:<br>
>   rL LLVM<br>
><br>
> <a href="http://reviews.llvm.org/D15245" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15245</a><br>
><br>
> Files:<br>
>   lib/Transforms/IPO/Inliner.cpp<br>
><br>
> Index: lib/Transforms/IPO/Inliner.cpp<br>
> ===================================================================<br>
> --- lib/Transforms/IPO/Inliner.cpp<br>
> +++ lib/Transforms/IPO/Inliner.cpp<br>
> @@ -296,6 +296,17 @@<br>
>    if (InlineHint && HintThreshold > Threshold &&<br>
>        !Caller->hasFnAttribute(Attribute::MinSize))<br>
>      Threshold = HintThreshold;<br>
> +  // If profile information is available, use that to prioritize hot functions.<br>
> +  // FIXME: The heuristic used here is based on preliminary SPEC tuning and<br>
> +  // may not be optimal. Replace this with a well-tuned heuristic based on<br>
> +  // *callsite* hotness and not callee hotness.<br>
> +  auto EntryCount = Callee->getEntryCount();<br>
> +  auto MaxFunctionCount = Callee->getParent()->getMaximumFunctionCount();<br>
> +  if (EntryCount && MaxFunctionCount &&<br>
> +      EntryCount.getValue() >=<br>
> +          (uint64_t)(0.3 * (double)MaxFunctionCount.getValue())) {<br>
> +    Threshold = HintThreshold;<br>
> +  }<br>
<br>
</div></div>Moving this out of the frontend to here makes sense, but I have a couple<br>
of questions.<br>
<br>
- Does this only apply when we've supplied actual profile data, or can<br>
  we hit it based off of the heuristic counts in no-profile-data mode?<br>
  If the latter, this isn't quite NFC.<br>
<br></blockquote><div>It applies only when there is profile data since entry count and maximum function count come only from profile data.</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">
- Can the same be done for the "cold" attribute the frontend also applies?<br>
<div><div><br></div></div></blockquote><div>The difference between the inlinehint and cold attributes is that the latter is used not just by the inliner. For instance, branch probability info. I can move it to the backend and replace all calls to hasFnAttr(Attribute::Cold) with a wrapper that also returns true if the count is below the threshold. Do you want that change to be in this patch?</div><div><br></div><div>regards,</div><div>Easwaran</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"><div><div>
><br>
>    // Listen to the cold attribute when it would decrease the threshold.<br>
>    bool ColdCallee = Callee && !Callee->isDeclaration() &&<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>