Re: C++ PATCH: Fix -O3

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Thu, 3 May 2001, Mark Mitchell wrote:

> >>>>> "Daniel" == Daniel Berlin <dan@www.cgsoftware.com> writes:
>
>     Daniel> Can you then disable the test to see if we've inlined too
>     Daniel> many things already?  We already have a heuristic in there
>     Daniel> to not inline things that are oto large, it doesn't seem
>     Daniel> to make sense to stop inlining simply because you've
>     Daniel> inlined 8 other things in this module.
>
> This patch makes us inline *more* things, not fewer.
Yes, i realize this.
 >
> I assume you're referring to the bit where we stop inlining once we've
> reached a certain maximum number of statements in a function?

No, there is actually a test a little lower than this that says:
"Even if this function is not itself too big to inline, it might be that
we've done so much inlining already that we dont' want to risk inlining
anymore".

It then sees if id->inlined_stmts + the number of statements in the
function is > MAX_INLINE_INSNS.

I agree with the idea, i think it's the wrong appraoch, unless i'm
misunderstanding the inline data struct that gets passed around, and it's
really reset on every function (I don't believe it is, last i looked,
since it saves the functions and whatnot in there).

What we really should be checking is the number of statements in the
funciton we are inlining into,which would be DECL_NUM_STMTS
(VARRAY_TREE  (id->fns, 0));, and making sure *that* won't be >
MAX_INLINE_INSNS if we do this inline.
Right now, it's comparing against the sum of the number of insns we've
inlined over the entire compilation. So we only inline so much over the
course of the entire compilation.
This seems wrong, and as a heuristic, it doesn't make much sense.

 > > No, we very much need that heuristic.  That's what keeps us from
> inlining absolutely *everything* into one gigantic function, which
> drives memory usage through the roof.

DECL_NUM_STMTS (VARRAY_TREE (id_fns, 0)) is incremented right before
id->inlined_stmts is incremented, so it would grow the same. It would
just be reset with every new function we compile.
Right now we say:

If the function we are considering inlining is too large, don't inline it
If the function we are considering inlining would make the number of
inlined insns over the course of entire compilation too large, don't
inline it.

We should say
If the funciton we are considering inlining is too large, don't inline
it.
If the function we are considering inlining *into* will get too large by
performing this inlining,  don't inline it.


This should also prevent inlining everything into one huge function,
while at the same time, not screwing over everything after a certain
point in the compilation, just because you had a lot of small inline
functions that got integrated into some other function. Right now, it
won't inline them into later functions.

 >
> -- > Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com
>