This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO merge][14/15] cgraph/gimple/ipa changes
On Tue, 29 Sep 2009, Jan Hubicka wrote:
> > 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.
always-inline is a correctness thing - I'd rather not sorry() because
during LTO the inlining fails. All always-inline required inlines
should have been resolved per TU.
Richard.