This is the mail archive of the
mailing list for the GCC project.
Re: [RFA] Kill artificial inlining limit
- From: Michael Matz <matz at suse dot de>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 13 May 2003 14:34:57 +0200 (CEST)
- Subject: Re: [RFA] Kill artificial inlining limit
On Tue, 13 May 2003, Richard Guenther wrote:
> honoured all the time due to some strange code in tree-inline.c, so
It's not strange, it's real cut-off code to limit possible bad effects.
That you get different results by removing it indicates, that it indeed
> I propose to kill the "doesnt happen in real code" artificial inlining
> limit to expose another 30% performance increase in POOMA based scientific
> See also thread at http://gcc.gnu.org/ml/gcc/2003-05/msg00654.html
> Also Gerald Pfeifer confirmed that the removed codepath does not trigger
> in his codebase and such the patch does not make any difference for him.
IIRC there were other code-bases (Steven Bosscher?) which compiled awfully
slow with the default setting of min-inline-insns. _That_ code would
compile even slower when the limit is removed alltogether.
It would be better to adjust the inlining heuristic to inline your very
small constructors despite the limit. Or I envision to let the maximum
size of inlinable functions depend on the remaining size up to a certain
limit (so that later only smaller functions are inlined).
But I think throwing away the limit at all wouldn't be advisable.