This is the mail archive of the
mailing list for the GCC project.
Re: [RFA] Kill artificial inlining limit
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Michael Matz <matz at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 13 May 2003 14:55:03 +0200 (CEST)
- Subject: Re: [RFA] Kill artificial inlining limit
On Tue, 13 May 2003, Michael Matz wrote:
> 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
> triggers sometimes.
Indeed. So the comment above the code is clearly wrong ;)
> > I propose to kill the "doesnt happen in real code" artificial inlining
> > limit to expose another 30% performance increase in POOMA based scientific
> > applications.
> > 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.
Maybe. Mine does. But it pays off in performance.
> It would be better to adjust the inlining heuristic to inline your very
> small constructors despite the limit.
This is the purpose of --param min-inline-insns, but this is overridden
by this (bogous) cutoff.
> 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).
The limit of function size to be inlined is decreased by a slope function
for multiple inlining already, the artificial cutoff limits the sum of
inlined functions size into a function -- in a non controllable way.
I really need to tune parameters to tell gcc somehow "inline all stuff
inside this loop", i.e. make it "flat". If we can achieve this in some
other way I would be even more happy.
But I again state, the artificial cut-off is broken, as it goes against
the --param min-inline-insns purpose.
Oh - if I disable this cut-off most of the compile time is spent inside
loop-analysis. Maybe there could be some improvements made there (run cse,
gcse first, f.i.).
> But I think throwing away the limit at all wouldn't be advisable.
I think it would be ;) Or at least make it a --param, so I can turn it
Richard Guenther <richard dot guenther at uni-tuebingen dot de>