<div dir="ltr">(Resending after  removing <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a> and using <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 3:08 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">Hi Philip,<div><br></div><div> Is there any update on this? I've been sending patches to get rid of the callee hotness based inline hints from the frontend and move the logic to the inliner. The next step is to use the callsite hotness instead. I also want to focus on the infrastructure to enable this and what I've been experimenting with is similar to your two alternative approaches:</div><div class="gmail_extra"><br><div class="gmail_quote"><span class=""><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"><br>
Alternate Approaches:<br>
1) We could just recompute BFI explicitly in the inliner right before passing the result to ICA for the purposes of prototyping. If this was off by default, this might be a reasonable scheme for investigation.  This could likely never be enabled for real uses.<br>
2) We could pre-compute BFI once per function within a given SCC and then try to keep it up to date during inlining.  If we cached the call frequencies for the initial call sites, we could adjust the visit order to minimize the number of times we need to recompute a given functions block frequencies.  (e.g. we can look at all the original call sites within a function before looking at newly inlined ones)<br>
<br></blockquote><div><br></div></span><div>My proposal is very similar (perhaps identical) to your option 2 above. I don't understand the part where you talk about adjusting the visit order to minimize BFI computation. </div><div><br></div><div>BFI computation:  BFI for a function is computed on demand and cached. </div><div><br></div><div>Update: When 'bar' gets inlined into 'foo', the BFI for 'foo' is updated. Let OldBB in 'bar' gets cloned as NewBB in 'foo'.  NewBB's block frequency can be incrementally computed from OldBB's block frequency, entry block frequency of 'bar' and the frequency of the block containing the 'foo' -> 'bar' callsite. Even when the new CGSCC level BFI analysis is in place, this incremental update is useful to minimize computation. </div><div><br></div><div>Invalidation:  Once inlining is completed in an SCC (at the end of runOnSCC), the entries for functions in that SCC are invalidated since other passes run by the CGSCC pass manager (including those run by the function pass manager run under CGSCC pass manager) might affect the computed BFI for the functions in the SCC. </div><div><br></div><div>When the new PM infrastructure and a CGSCC based BFI analysis is in place, the transition should be easy assuming it will provide getBFI(Function *) and invalidateBFI(Function *) interfaces. BFI for a function is computed at most twice in this approach. Thoughts?</div><div><br></div><div><br></div><div>Thanks,</div><div>Easwaran</div><span class=""><div> <br></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">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>