Re: Inlining and estimate_num_insns

[Jan Hubicka <jh at suse dot cz>]

> On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> > On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <hubicka@ucw.cz> wrote:
> > 
> > > Concerning growth limits:
> > >
> > > If you take a look on when -finline-unit-growth limit hits, it is clear
> > > that it hits very often on small units (several times in the kernel,
> > > testsuite and such) just because there is tinny space to manuever.  It
> > > hits almost never on medium units (in GCC bootstrap it hits almost
> > > never) and almost always on big units
> > >
> > > My intuition alwas has been that for larger units the limits should be
> > > much smaller and pooma was major counter example.  If we suceed solving
> > > this, I would guess we can introduce something like small-unit-insns
> > > limit and limit size of units that exceeds this.  Does this sound sane?
> > 
> > POOMA hitting the unit-growth limit is caused by the abstraction penalty
> > of the inliner and is no longer an issue with the new code size estimate.
> > Though with the new estimate our INSNS_PER_CALL is probably too high,
> > so we're reducing the unit-size too much inlining one-statement functions
> > and as such getting more room for further inlining and finally regress badly
> > in compile-time (as max-inline-insns-single is so high we're inlining stuff
> > we shouldn't, but as it fit's the unit-growth limit now, we do ...)
> 
> Experimenting further with replacing INSNS_PER_CALL by one plus the
> move cost of the function arguments shows promising results, also not
> artificially overestimating RDIV_EXPR and friends helps us not regress
> on some testcases if we lower the default limits to 100.  But I have too many
> patches pending now - I'll let the dust settle down for now.  Maybe we
> should create a branch for the inlining stuff, or use tree-profiling branch
> (though that has probably too many unrelated stuff).

Problem with separate branch would be that tree-profiling already
contains a lot of code for 4.1 that seriously affect inlining decisions,
so probably 4.1 stuff should be tuned against that. We need some
stabilization on tree-profiling right now and I hope to move on inlining
stuff there later this week.

Honza
> 
> Richard.