Re: [LTO merge][14/15] cgraph/gimple/ipa changes

[Jan Hubicka <hubicka at ucw dot cz>]

> On Tue, Sep 29, 2009 at 9:24 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> >> + ? ? ?/* Note that it is not strictly necessary to schedule an early
> >> + ? ? ?inline pass here. ?However, some test cases (e.g.,
> >> + ? ? ?g++.dg/other/p334435.C g++.dg/other/i386-1.C) expect extern
> >> + ? ? ?inline functions to be inlined even at -O0. ?This does not
> >> + ? ? ?happen during the first early inline pass. ?*/
> >
> > The planned fixes for extern inline stuff didn't happen, I guess?
> 
> Right.  I think what should happen is that the early inlining
> phase from running cc1 should do all always_inline inlines
> (thus the IPA inliner never should see not inlined always_inline
> functions), and after that we'll simply ignore always_inline
> (in particular always_inline doesn't count cross TUs but is strictly
> local to a single TU).

Early inlining works in topological order.  In the case of cyclic
cgraphs it can't always pick all alternatives (and even if you schedule
two oftem)

With current handling of extern inline stuff we are losing optimization
oppurtunities here.  Early inliner is quite conservative in addition to
not being handle cycles well, so now static inline is getting handled
more aggressively than extern inline.  We really need proper
representation of extern inline behaviour)
> 
> Somehow always-inline "opportunities" leak to the IPA inliner
> even without LTO.

I wonder about cross-TU always-inline behaviour.  Is it really something
we need to disable? Similarly with flatten.
Obviously code generated would change LTO or non-LTO.  BUt I would
expect soon LTO aware programs to be written that would benefit from
cross-TU always-inline/flatten stuff and it seems to me that doing this
default makes sense too.

I guess it is not different from situation where adding indirect inlinig
made always_inline/flatten stronger than previously.

Honza
> 
> Richard.