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]

Re: [PATCH] New c++ inliner



> 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
> function
> 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                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


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