On Tue, 1 Mar 2005 16:49:04 +0100, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Tue, 1 Mar 2005 16:14:14 +0100, Jan Hubicka <[EMAIL PROTECTED]> 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). Richard.
