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

[Devang Patel]

On Sep 4, 2008, at 1:31 AM, Duncan Sands wrote:

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

I disagree. If the programmer did not want F to get very big then he  
should not use -O3 to compiler F.

-
Devang

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