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

[Duncan Sands]

> > 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.
> 
> I disagree. If the programmer did not want F to get very big then he  
> should not use -O3 to compiler F.

Well, maybe.  People doing LTO might be surprised that the routines
they carefully compiled originally using -Os have grown jumbo-sized
in the final bitcode.  However probably this whole scenario is not
really possible: since the inliner works from callees back to
callers, only routines directly called from fast.c (i.e. S not T)
should be inlined into fast.c routines like F, rather than them
and the routines they call and the routines those call etc, in
the fattening cascade I was worried about.

So I think in fact there is no issue here after all!

Ciao,

Duncan.