Inlining and estimate_num_insns

[Richard Guenther]

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

Richard.