Re: [PATCH] Fix inlining of always_inline functions

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, 6 Jan 2010, Jan Hubicka wrote:
> 
> > > 
> > > This fixes a testcase I produced reducing PR42632.  During
> > > early inlining we inline a non-always-inline function into
> > > an always-inline function.  This breaks inlining when
> > > being in a cycle and part of it is marked always-inline.
> > > 
> > > Note that inlining into an always-inline function incrementally
> > > is always bogus - this either pessimizes size of callers of
> > > the always-inline function or is premature as the function would
> > > be inlined into the caller of the always-inline function anyway.
> > > It might save some compile-time but I consider this unlikely
> > > and it does indeed break inlining in cycles as seen by the testcase.
> > > 
> > > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > 
> > > Honza, any objections to this?
> > 
> > Well, I was always bit in favour of declaring always inline bad idea on
> > cyclic callgraphs, but I guess this will work too and won't cause much
> > of code quality issues (by disabling early inlining you also makes early
> > opt less effective and thus function calling always_inline functions
> > after inlining them will get bigger code size estimates in real
> > inliner).
> > But I guess these beasts are not common enough to matter.
> 
> Well, as we iterate during early inlining you'll simply first
> inline the always-inline functions and then inline the callees
> into the inlined-to but not always-inline function.
> Thus for F -> F' -> F'' -> F when only F' is always-inline
> you inline F' but not into F', you'll still end up inlining
> F'' into F if it is small enough.
> 
> So indeed I don't see a problem here.

Hmm, right.  Iteration wasn't added for this purpose but it should work
;)

Honza
> 
> Richard.