This is the mail archive of the gcc-patches@gcc.gnu.org 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


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.

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

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.


Ciao,
Michael.


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