<div dir="ltr"><p class="gmail-md-end-block gmail-md-p gmail-md-focus" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">In my GSoC 2021, my goal is to evaluate the value of different callsite visiting orderings, which is inspired by paper[1][2]</span><span class="gmail-md-plain" style="box-sizing:border-box">. I've already enabled doing such an exploration within the constraints of the current SCC inliner (<a href="https://reviews.llvm.org/D104028">https://reviews.llvm.org/D104028</a>)</span><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">. Exploring more advanced callsite orderings is not possible with the current SCC inliner. The current SCC inliner runs on each SCC in a bottom-up traversal, which means that the inline order is limited to a bottom-up order. </span></p><p class="gmail-md-end-block gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain" style="box-sizing:border-box">To address this limitation, I would like to add a module inliner, which processes all call sites in a given module at a time instead of a given SCC. This gives us flexibility on the order in which we process call sites.</span></p><p class="gmail-md-end-block gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain" style="box-sizing:border-box">The module inliner would be disabled by default, to minimize code churn to the existing codebase and make it easier to </span>remove it. Also, to avoid unnecessary abstractions, which would complicate the existing codebase, some code is copied from SCC inliner. Lastly, to foster collaboration, I would propose landing it in trunk rather than a branch.</p><p class="gmail-md-end-block gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">Best wishes,</span></p><p class="gmail-md-end-block gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">Liqiang Tao</span></p><p class="gmail-md-end-block gmail-md-p" style="box-sizing:border-box;line-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51);font-family:"Open Sans","Clear Sans","Helvetica Neue",Helvetica,Arial,sans-serif;font-size:16px"><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">----

<span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">[1] Aleksandar Prokopec, Gilles Duboscq, David Leopoldseder, and Thomas Würthinger. 2019. An optimization-driven incremental inline substitution algorithm for just-in-time compilers. In Proceedings of the 2019 IEEE/ACM International Symposium on Code Generation and Optimization (CGO 2019).</span><span class="gmail-md-softbreak" style="box-sizing:border-box">
</span><span class="gmail-md-plain gmail-md-expand" style="box-sizing:border-box">[2] Dhruva R. Chakrabarti and Shin-Ming Liu. 2006. Inline Analysis: Beyond Selection Heuristics. In Proceedings of the International Symposium on Code Generation and Optimization (CGO '06).</span>

</span></p></div>