[llvm-commits] [llvm] r55745 - /llvm/trunk/lib/Transforms/IPO/Inliner.cpp

Duncan Sands baldrick at free.fr
Thu Sep 4 01:31:45 PDT 2008


Hi Devang,

> Update inline threshold for current function if the notes say, optimize for size.

if a function is marked opt-size, then I think you need to ensure both
that nothing big is inlined into it, *and* that it is not itself inlined
into anything if it is big.  Consider the following situation: I compile
a file small.c using -Os because it is more important that these routines
compile to something small than to something fast.  A second file fast.c
uses routines from small.c but is compiled at (say) -O3.  Now I link the
bitcode small.bc and fast.bc together, and reoptimize.

What may happen is this: suppose a routine F in fast.c calls S in small.c,
while S itself calls T in small.c, etc.

Since there is no inline limit on F, the inliner may happily inline S into
F even if S is large.  Now F contains calls to T, but *F still has no inline
limit* (the opt-size note on S was discarded when it was inlined into F).
So the inliner may happily now inline T into F even if T is large.  Rinse
and repeat.  The final result is that the inliner may end up creating a big
function F which contains most of small.c inlined.  This is presumably not
what the programmer wanted.

Well, I'm not sure if this can really happen in practice.  If it can,
then the simplest solution is presumably to refuse to inline opt-size
functions into a call-site if the opt-size function is too large.

Ciao,

Duncan.



More information about the llvm-commits mailing list