This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Kill artificial inlining limit

On Tue, 13 May 2003, Michael Matz wrote:

> Hi,
> 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
> >
> > 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


> Ciao,
> Michael.

Richard Guenther <richard dot guenther at uni-tuebingen dot de>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]