<br><br><div class="gmail_quote">On Wed, Nov 24, 2010 at 12:37 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca">nicholas@mxc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Xinliang David Li wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, I browsed the LLVM inliner implementation, and it seems there is<br>
room for improvement.  (I have not read it too carefully, so correct me<br>
if what I observed is wrong).<br>
<br>
First the good side of the inliner -- the function level summary and<br>
inline cost estimation is more elaborate and complete than gcc. For<br>
instance, it considers callsite arguments and the effects of<br>
optimization enabled by inlining.<br>
<br>
Now more to the weakness of the inliner:<br>
<br>
1) It is bottom up.  The inlining is not done in the order based on the<br>
priority of the callsites.  It may leave important callsites (at top of<br>
the cg) unlined due to higher cost after inline cost update. It also<br>
eliminates the possibility of inline specialization. To change this, the<br>
inliner pass may not use the pass manager infrastructure .  (I noticed a<br>
hack in the inliner to workaround the problem -- for static functions<br>
avoid inlining its callees if it causes it to become too big ..)<br>
<br>
2) There seems to be only one inliner pass.  For calls to small<br>
functions, it is better to perform early inlining as one of the local<br>
(per function) optimizations followed by scalar opt clean up. This will<br>
sharpen the summary information.  (Note the inline summary update does<br>
not consider the possible cleanup)<br>
</blockquote>
<br></div>
Hi David,<br>
<br>
You're correct that there's only one inliner pass, but I don't understand how an early inliner would help. In LLVM's case, after we inline one function into another, we run the entire stack of per-function optimizations on it before deciding whether to inline it into its caller. This sharpens the summary information before the inliner looks at the next SCC, as we go bottom up. Is there something more that early inlining would do for us that isn't achieved with this model?<br>
</blockquote><div><br></div><div>Interesting -- LLVM does perform on the fly cleanups during inlining transformation -- this will make summary update precise. One thing I notice from the debug pass dump is that the 'deduce function attribute' pass happens before the clean up -- Is it intended?</div>
<div><br></div><div>Thanks,</div><div><br></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>
(Actually, there is another inliner pass, but it's for __attribute__((always_inline)) so it's rather uninteresting.)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3)  recursive inlining is not supported<br>
<br>
4) function with indirect branch is not inlined. What source construct<br>
does indirect branch instr correspond to ? variable jump?<br>
</blockquote>
<br></div>
Right. It's for "goto *ptr;".<br>
<br>
Nick<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
5) fudge factor prefers functions with vector instructions -- why is that?<br>
<br>
6) There is one heuristc used in inline-cost computation seems wrong:<br>
<br>
<br>
   // Calls usually take a long time, so they make the inlining gain<br>
smaller.<br>
   InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty;<br>
<br>
Does it try to block inlining of callees with lots of calls? Note<br>
inlining such a function only increase static call counts.<br>
<br>
<br>
Thanks,<br>
<br>
David<br>
<br>
<br>
<br></div>
_______________________________________________<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" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
<br>
</blockquote></div><br>