This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] New c++ inliner
- To: Nathan Sidwell <nathan at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Subject: Re: [PATCH] New c++ inliner
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 13 Jul 2001 12:52:15 -0700
- cc: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>, Daniel Berlin <dan at cgsoftware dot com>
> This algorithm does a bottom up inlining. What I do is
> 1) do non-inline optimizations on the current function
> 2) gather a list of all the inlinable call sites in the current
> 3) fully optimize each of those callees. This includes the
> step of inlining into the body of the callee. There is a new
> flag for FUNCTION_DECLS indicating whether it has already under
> gone this optimization step.
I am concerned about this. In particular, the reason we did top-down
inlining was that if you have A calls B calls C calls D and all
are inline, then you get four copies of D, three of C, two of B, i.e.,
a quadratic-ish explosion in copying. By not inlining into B (unless it
is output directly) we eliminate this problem. I understand your
response to this issue, but I'm still concerned.
This matters less if the thresholds are smaller of course.
Q) Doesn't DECL_NUM_STMTS count the number of statements in a
function, not the number of tree nodes.
A) Yes it does, we need to change that. Also, we'll need to recalculate
it when other AST optimizations start mangling the tree.
FWIW, I bet we don't have to change this. All we need is some kind
of approximate bigness measurement. Statements, tree nodes, even number
of tokens in the input would all probably correlate reasonably well.
There are, of course, Really Big Statements, but there are also really
big expressions that expand to almost no code.
Overall, I still think we may be over-thinking this, relative to all the
other problems we have. I'd still be tempted just to crank the default
parameter down, see how that does, and then revisit this issue if we
have data that suggests that poor inlining is one the major problems
we have in terms of getting good code generation.
Mark Mitchell email@example.com
CodeSourcery, LLC http://www.codesourcery.com