<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">Hi Liq,</div>
<div class=""><br class="">
</div>
<div class="">This is a cool project, good luck!</div>
<div class=""><br class="">
</div>
<div class="">At Azul we spent quite a bit of time looking into inlining. At this point we run a custom inliner pass which is similar to the paper in many aspects.</div>
<div class=""><br class="">
</div>
<div class="">This is a loaded paper as it touches multiple aspects of inlining. Some of the aspects are applicable to the LLVM inliner others are not. I'm curious what you mean by porting this algorithm to the LLVM inliner. These are the main aspects as I
remember them.</div>
<div class=""><br class="">
</div>
<div class="">* In the context of just-in-time compilation the full call graph is not available to the inliner. Because of that inliners in just-in-time compilers tend to be top-down. A part of this paper is heuristics on how to explore the call graph starting
from a single top level method. This is not relevant to the LLVM inliner because it has the call graph available.</div>
<div class=""><br class="">
</div>
<div class="">* The clustering aspect. This can be viewed as a simulation of bottom up inlining without actually inlining. Clustering is performed in bottom-up order on the subgraph explored by the heuristics mentioned above. Bottom-up inlining achieves very
similar results by representing clusters as functions with inlined callees. So I am not sure that this aspect is relevant for the LLVM inliner.</div>
<div class=""><br class="">
</div>
<div class="">* The cost/benefit model. They do cost/benefit analysis by specializing callees and propagating the facts from the callers into the specialized functions. Then they count how many simplifications happened after this specialization. LLVM does something
similar in the inline cost analysis but without specializing the functions. Graal's inliner propagates the facts to the callees, runs the simplifications and then observes how many simplifications took place. LLVM's inliner looks at the callees and the facts
available in the caller, and analyzes what kind of simplifications would happen once these facts are available after inlining. The inline cost analysis in LLVM has a very rudimentary benefit analysis. This aspect can be improved.</div>
<div class=""><br class="">
</div>
<div class="">* Deep inlining trials. Graal's inliner propagates facts into callees multiple levels deep. For example, if a constant is passed as an agreement into a call foo and foo passes this argument into bar where the value is actually used, the constant
will be propagated all the way to bar. This makes it possible to recognize simplifications multiple levels deep. This is a very interesting ability. Note that a bottom up inliner might be less sensitive to this, because it tends lift the code up to the callers,
effectively compressing deep call chains. Because of that a bottom-up inliner can sometimes get away with a single level inlining trial.</div>
<div class=""><br class="">
</div>
<div class="">You mention grouping locally related functions in the document. Looks like this is mostly about improving the cost/benefit model. Do I understand it right?</div>
<div class=""><br class="">
</div>
<div class="">Artur</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On May 21, 2021, at 6:42 AM, Liqiang Tao via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Dear All,
<div class=""><br class="">
</div>
<div class="">I'm Liqiang Tao, a graduate student at the University of Tokyo, Japan. You can call me Liq or Tao, which is easy to pronounce I think.</div>
<div class="">My project is about exploring whether it is helpful to come up with locally optimal inlining decisions with the profile, which generalize the existing LLVM inline deferral logic.</div>
<div class="">You could access my full proposal here - <a href="https://docs.google.com/document/d/1nhJKSdPTtWzTbAsY3vvTlXbLZFI9GQMnU5F4d-3JLWc/edit#heading=h.us242diaa3ay" class="">https://docs.google.com/document/d/1nhJKSdPTtWzTbAsY3vvTlXbLZFI9GQMnU5F4d-3JLWc/edit#heading=h.us242diaa3ay</a></div>
<div class="">I think it would be an exciting summer with my great mentors Kazu Hirata and Mircea Trofin.</div>
<div class=""><br class="">
</div>
<div class="">Best Wishes,</div>
<div class="">Liqiang Tao</div>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>