[LLVMdev] LLVM Inliner

[Reid Kleckner]

On Tue, Nov 23, 2010 at 8:07 PM, Xinliang David Li <xinliangli at gmail.com> wrote:
> Hi, I browsed the LLVM inliner implementation, and it seems there is room
> for improvement.  (I have not read it too carefully, so correct me if what I
> observed is wrong).
> First the good side of the inliner -- the function level summary and inline
> cost estimation is more elaborate and complete than gcc. For instance, it
> considers callsite arguments and the effects of optimization enabled by
> inlining.
> Now more to the weakness of the inliner:
> 1) It is bottom up.  The inlining is not done in the order based on the
> priority of the callsites.  It may leave important callsites (at top of the
> cg) unlined due to higher cost after inline cost update. It also eliminates
> the possibility of inline specialization. To change this, the inliner pass
> may not use the pass manager infrastructure .  (I noticed a hack in the
> inliner to workaround the problem -- for static functions avoid inlining its
> callees if it causes it to become too big ..)
> 2) There seems to be only one inliner pass.  For calls to small functions,
> it is better to perform early inlining as one of the local (per function)
> optimizations followed by scalar opt clean up. This will sharpen the summary
> information.  (Note the inline summary update does not consider the possible
> cleanup)
> 3)  recursive inlining is not supported
> 4) function with indirect branch is not inlined. What source construct does
> indirect branch instr correspond to ? variable jump?

This corresponds to functions that use GCC's labels-as-values
extension, not things like switch statements or virtual calls, so this
really only applies to things like interpreter loops, which you don't
usually want to inline.

> 5) fudge factor prefers functions with vector instructions -- why is that?

I'm guessing that vectorized instructions are an indicator that the
function is a hotspot, and should therefore be inlined.

> 6) There is one heuristc used in inline-cost computation seems wrong:
>
>   // Calls usually take a long time, so they make the inlining gain smaller.
>   InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty;
> Does it try to block inlining of callees with lots of calls? Note inlining
> such a function only increase static call counts.

I'm guessing the heuristic is that functions with lots of calls are
heavy and spend a lot of time in their callees, so eliminating the
overhead of one call isn't worth it.

Reid