[LLVMdev] LLVM Inliner

[Nick Lewycky]

Xinliang David Li 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)

Hi David,

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?

(Actually, there is another inliner pass, but it's for 
__attribute__((always_inline)) so it's rather uninteresting.)

> 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?

Right. It's for "goto *ptr;".

Nick

> 5) fudge factor prefers functions with vector instructions -- why is that?
>
> 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.
>
>
> Thanks,
>
> David
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev